Showing posts with label Tutorial Android Kotlin. Show all posts
Showing posts with label Tutorial Android Kotlin. Show all posts

Friday, January 10, 2020

Aplikasi Hamilton yang dibuat dalam 3 bulan dengan Flutter meraih lebih dari 1 juta penginstalan [Video]

Aslinya diposting pada Flutter Medium oleh Martin Aguinis


Hamilton dan Posse, agensi desain dan pengembangan di New York, hanya membutuhkan tiga bulan untuk mengembangkan dan meluncurkan aplikasi seluler bagi acara Broadway yang sedang hit. Bagaimana mereka melakukannya? Menggunakan Flutter, framework UI seluler Google yang baru.

Menjangkau jutaan pengguna — dengan setengah juta pengguna aktif bulanan yang luar biasa dan dipublikasikan di App Store dan Google Play— aplikasi memungkinkan penggemar memasukkan lotre tiket, membeli merchandise, bermain trivia, berfoto selfie dengan #HamCam, membaca berita dan interviu terupdate, dan banyak lagi.

Tonton studi kasus video ini untuk melihat bagaimana Flutter terus membantu aplikasi seperti Hamilton agar berhasil di iOS dan Android. Anda bisa membaca detail selengkapnya tentang pengembangan aplikasi ini pada entri blog Posse.

Flutter gratis dan open source. Mulai sekarang di flutter.io. Kami tak sabar ingin segera melihat kreasi Anda!

//developers-id.googleblog.com/2018/04/video-aplikasi-hamilton-yang-dibuat.html

Thursday, October 24, 2019

Kotlin untuk Android

Hari ini menandai awal KotlinConf 2018 - pertemuan tatap muka tahunan terbesar komunitas Kotlin. 2018 menjadi tahun yang besar bagi Kotlin, karena bahasa ini semakin banyak diadopsi dan disukai developer. Bahkan, 27% dari 1.000 aplikasi Android teratas di Google Play sudah menggunakan Kotlin. Yang lebih penting lagi, developer Android sangat menyukai bahasa ini dengan tingkat kepuasan lebih dari 97% dalam survei terbaru kami. Tidaklah mengherankan sehingga Kotlin terpilih sebagai bahasa #2 yang paling disukai dalam survei StackOverflow 2018.

Google mendukung Kotlin sebagai bahasa pemrograman kelas-satu untuk pengembangan Android. Dalam 12 bulan terakhir, kami telah memberikan sejumlah perbaikan penting untuk pengalaman developer Kotlin. Ini termasuk SDK ramah-Kotlin, Android KTX, pemeriksaan Lint baru dan berbagai perbaikan dukungan Kotlin di Android Studio. Kami juga telah meluncurkan dukungan Kotlin dalam dokumentasi resmi kami, contoh-contoh unggulan baru di Kotlin, kursus Kotlin Bootcamp Udacity baru, #31DaysOfKotlin dan konten mendalam lainnya. Kami berkomitmen untuk terus meningkatkan pengalaman developer Kotlin.

Seiring dengan terus berkembangnya bahasa, semakin banyak developer yang menemukan keunggulan Kotlin di seluruh dunia. Baru-baru ini, kami melakukan perjalanan ke India dan bekerja dengan developer lokal seperti Zomato untuk lebih memahami bagaimana adopsi Kotlin telah menguntungkan pengembangan Android mereka. Zomato adalah layanan penelusuran & penemuan restoran terkemuka yang beroperasi di 24 negara, dengan lebih dari 150 juta pengguna setiap bulan. Kotlin membantu Zomato mengurangi jumlah baris kode di aplikasi mereka secara signifikan, dan Kotlin juga membantu mereka menemukan cacat penting dalam aplikasi mereka pada waktu kompilasi. Anda bisa menonton kisah adopsi Kotlin mereka dalam video di bawah ini.

Android Developer Story: Zomato uses Kotlin to write safer, more concise code.
Melampaui Android, dengan senang hati kami umumkan bahwa tim Google Cloud Platform meluncurkan portal Kotlin khusus hari ini. Ini akan mempermudah developer dalam menemukan sumber daya yang terkait dengan Kotlin di Google Cloud. Kami ingin membuat penggunaan Kotlin semudah mungkin bagi Anda, baik di seluler atau di Cloud.



Halaman beranda Kotlin di Google Cloud Platform
Mengadopsi bahasa baru adalah keputusan yang besar bagi kebanyakan perusahaan, dan Anda harus yakin bahwa bahasa yang Anda pilih memiliki masa depan cerah. Itulah sebabnya Google bergabung dengan JetBrains dan mendirikan Kotlin Foundation. Kotlin Foundation akan memastikan bahwa Kotlin terus berkembang pesat, tetap bebas dan terbuka. Anda bisa mempelajari lebih lanjut tentang Kotlin Foundation di sini.

Sangat menarik menjadi developer Kotlin. Jika Anda belum mencoba Kotlin, kami mendorong Anda untuk bergabung dengan komunitas global yang sedang berkembang ini. Anda bisa memulai dengan mengunjungi kotlinlang.org atau halaman Kotlin Developer Android.
Share on Twitter Share on Facebook

lihat selengkapnya disini https://developers-id.googleblog.com/2018/10/momentum-kotlin-untuk-android-dan.html

Wednesday, October 23, 2019

backup Android Anda

backup Android Anda

Android adalah semua tentang pilihan. Karena itulah, Android berusaha menyediakan banyak pilihan bagi pengguna untuk melindungi data mereka. Dengan menggabungkan Android Backup Service dan Google Cloud Titan Technology, Android mengambil langkah tambahan untuk mengamankan data pengguna sembari menjaga privasi mereka.

Mulai Android Pie, perangkat bisa memanfaatkan kemampuan baru ketika data aplikasi yang di-backup hanya bisa didekripsi oleh kunci yang dihasilkan secara acak di klien. Kunci dekripsi ini dienkripsi menggunakan PIN/pola/kode sandi kunci pengguna, yang tidak diketahui oleh Google. Kemudian, material kunci yang dilindungi kode sandi ini dienkripsi ke chip keamanan Titan di lantai pusat data kami. Chip Titan dikonfigurasikan untuk hanya merilis kunci dekripsi backup ketika menerima klaim yang benar yang berasal dari kode sandi pengguna. Karena chip Titan harus mengotorisasi setiap akses ke kunci dekripsi, ia bisa memblokir akses secara permanen setelah terlalu banyak upaya yang salah dalam menebak kode sandi pengguna, sehingga mengurangi serangan brute force. Jumlah upaya yang salah dibatasi secara ketat oleh firmware Titan khusus yang tidak bisa diupdate tanpa menghapus isi chip. Secara desain, ini berarti bahwa tidak seorang pun (termasuk Google) bisa mengakses data aplikasi backup pengguna tanpa secara khusus mengetahui kode sandi mereka.

Untuk meningkatkan kepercayaan diri kami bahwa teknologi baru ini secara aman mencegah siapa pun mengakses data aplikasi yang di-backup pengguna, tim Android Security & Privacy menyewa ahli keamanan cyber global dan mitigasi risiko NCC Group untuk menyelesaikan audit keamanan. Beberapa hasilnya mencakup hal positif seputar proses desain keamanan Google, validasi kualitas kode, dan mitigasi untuk vektor serangan yang dikenal telah dipertimbangkan sebelum peluncuran layanan. Saat ada beberapa masalah yang ditemukan selama audit ini, para engineer segera memperbaikinya. Untuk detail selengkapnya tentang cara kerja layanan menyeluruh dan laporan terperinci temuan NCC Group, klik di sini.

Mendapatkan tinjauan eksternal untuk upaya keamanan kami adalah salah satu dari banyak cara kami dalam menunjukkan bahwa Google dan Android menjaga transparansi dan keterbukaan yang pada gilirannya akan membantu pengguna merasa aman ketika menyangkut data mereka. Baik itu 100-an jam data game atau preferensi personalisasi di Google app favorit Anda, informasi pengguna kami selalu terlindungi.

Kami ingin berterima kasih atas kontribusi Shabsi Walfish, Software Engineering Lead, Identity and Authentication untuk karya ini

lihat selengkapnya disini https://developers-id.googleblog.com/2018/11/google-melindungi-backup-anda.html

Tuesday, October 22, 2019

Memperkenalkan WorkManager



Ada banyak pertimbangan dan praktik terbaik untuk menangani pekerjaan latar belakang, yang diuraikan dalam seri entri blog Google Power. Salah satu hal yang berulang kali disebut adalah library Android Jetpack yang disebut WorkManager, yang memperluas kemampuan API framework JobScheduler dan mendukung Android 4.0+ (API 14+). WorkManager beta baru saja dirilis hari ini!
Entri blog ini adalah yang pertama dari seri baru WorkManager. Kita akan menjelajahi dasar-dasar WorkManager, bagaimana dan kapan waktu yang tepat menggunakannya, dan apa yang terjadi di balik layar. Kemudian kita akan membahas kasus penggunaan yang lebih kompleks.

Apa yang dimaksud dengan WorkManager?
WorkManager adalah salah satu Komponen Arsitektur Android dan merupakan bagian dari Android Jetpack, sebuah cara baru dan ringkas dalam cara membangun aplikasi Android modern.

WorkManager adalah library Android yang menjalankan pekerjaan latar belakang yang dapat ditangguhkan saat batasan pekerjaan terpenuhi.

WorkManager ditujukan untuk tugas-tugas yang membutuhkan jaminan bahwa sistem akan menjalankannya bahkan bila aplikasi ditutup.

Dengan kata lain, WorkManager menyediakan API ramah-baterai yang merangkum evolusi bertahun-tahun dari pembatasan perilaku latar belakang Android. Ini sangat penting untuk aplikasi Android yang perlu menjalankan tugas latar belakang!

Kapan waktu yang tepat menggunakan WorkManager
WorkManager menangani pekerjaan latar belakang yang perlu dijalankan ketika berbagai batasan terpenuhi, terlepas dari apakah proses aplikasi tersebut aktif atau tidak. Pekerjaan latar belakang bisa dimulai saat aplikasi berada di latar belakang, saat aplikasi berada di latar depan, atau saat aplikasi dimulai di latar depan tetapi beralih ke latar belakang. Apa pun yang dilakukan aplikasi, pekerjaan latar belakang harus terus dijalankan, atau dimulai ulang bila Android mematikan prosesnya.

Salah satu kekeliruan umum tentang WorkManager adalah bahwa ia diperuntukkan bagi tugas yang perlu dijalankan di thread “latar belakang” tetapi tidak perlu bertahan dari penutupan prosesnya. Bukan itu masalahnya. Ada solusi lain untuk kasus penggunaan ini seperti coroutines Kotlin, ThreadPools, atau library seperti RxJava. Anda bisa menemukan informasi selengkapnya tentang kasus penggunaan ini dalam panduan pemrosesan latar belakang.

Ada banyak situasi berbeda ketika Anda perlu menjalankan pekerjaan latar belakang, dan karena itu Anda membutuhkan solusi berbeda untuk menjalankan pekerjaan latar belakang. Entri blog tentang pemrosesan latar belakang ini menyediakan banyak informasi keren tentang kapan waktu yang tepat menggunakan WorkManager. Lihatlah diagram berikut yang bersumber dari blog:



Diagram dari Modern background execution in Android
Dalam kasus WorkManager, ia cocok digunakan untuk pekerjaan latar belakang yang harus diselesaikan dan dapat ditangguhkan.

Untuk memulai, tanyakan pada diri Anda sendiri:
Apakah tugas ini harus diselesaikan?

Jika aplikasi ditutup pengguna, apakah ia masih harus menyelesaikan tugas? Contohnya adalah aplikasi catatan dengan sinkronisasi jarak jauh; setelah Anda selesai menulis catatan, Anda tentu berharap aplikasi akan menyinkronkan catatan dengan server backend. Semuanya ini tetap berjalan bahkan bila Anda beralih ke aplikasi lain dan OS harus menutup aplikasi tersebut untuk mendapatkan kembali sebagian memori. Ini juga harus tetap berjalan bahkan bila Anda memulai ulang perangkat. WorkManager memastikan tugas diselesaikan.

Apakah tugas ini dapat ditangguhkan?
Bisakah kita menjalankannya nanti, atau ini hanya berguna jika tugas dijalankan sekarang? Jika tugas bisa dijalankan nanti, berarti tugasnya dapat ditangguhkan. Kembali ke contoh sebelumnya, tentu sangat menyenangkan jika catatan Anda langsung segera diupload, tetapi bila ini tidak memungkinkan dan sinkronisasi terjadi belakangan, itu bukanlah masalah besar. WorkManager menghormati pembatasan latar belakang OS dan mencoba menjalankan pekerjaan Anda dengan penggunaan baterai seefisien mungkin.

Jadi, sebagai panduan, WorkManager ditujukan untuk tugas-tugas yang membutuhkan jaminan bahwa sistem akan menjalankannya, bahkan bila aplikasi ditutup. WorkManager tidak ditujukan untuk pekerjaan latar belakang yang membutuhkan eksekusi segera atau pada waktu yang tepat. Jika Anda membutuhkan agar sebuah pekerjaan dieksekusi pada waktu yang tepat (seperti jam alarm, atau pengingat acara), gunakan AlarmManager. Untuk pekerjaan yang harus dieksekusi dengan segera tetapi berjalan lama, sering kali Anda harus memastikan bahwa pekerjaan dieksekusi saat berada di latar depan; apakah itu dengan membatasi eksekusi ke latar depan (dalam hal ini, pekerjaan tersebut tidak lagi berjalan sebagai pekerjaan latar belakang) atau menggunakan Foreground Service.

WorkManager bisa dan sebaiknya dipasangkan dengan API lain saat Anda perlu memicu beberapa pekerjaan latar belakang dalam skenario yang lebih kompleks:

Jika server Anda memicu pekerjaan, WorkManager bisa dipasangkan dengan Firebase Cloud Messaging.

Jika Anda mendengarkan siaran menggunakan penerima siaran dan kemudian perlu memicu pekerjaan yang berjalan lama, Anda bisa menggunakan WorkManager. Perhatikan bahwa WorkManager menyediakan dukungan untuk banyak Constraints umum yang biasanya datang sebagai siaran — dalam kasus ini, Anda tidak perlu mendaftarkan penerima siaran Anda sendiri.

Mengapa menggunakan WorkManager?
WorkManager menjalankan pekerjaan latar belakang sembari menangani masalah kompatibilitas dan menjalankan praktik terbaik bagi baterai dan kesehatan sistem untuk Anda.

Selain itu, dengan menggunakan WorkManager, Anda bisa menjadwalkan tugas periodik dan rantai tugas dependen yang kompleks: pekerjaan latar belakang dapat dieksekusi secara paralel atau berurutan, dan Anda bisa menetapkan urutan eksekusi. WorkManager menangani input dan output antar tugas dengan lancar.

Anda juga bisa menetapkan kriteria mengenai kapan tugas latar belakang harus dijalankan. Misalnya, tidak ada alasan untuk membuat permintaan HTTP ke server jarak jauh jika perangkat tidak memiliki sambungan jaringan. Jadi, Anda bisa menetapkan Constraint bahwa suatu tugas hanya dapat dijalankan ketika terdapat sambungan jaringan.

Sebagai bagian dari eksekusi terjamin, WorkManager mengelola seluruh pekerjaan Anda bila perangkat dimulai ulang dan proses dihentikan secara paksa. Anda juga bisa dengan mudah menentukan strategi coba lagi jika pekerjaan Anda dihentikan dan Anda ingin mencobanya lagi nanti.

  • Yang terakhir, WorkManager memungkinkan Anda mengawasi status permintaan pekerjaan sehingga Anda bisa mengupdate UI.
  • Sebagai ringkasan, WorkManager menawarkan keuntungan berikut:
  • Menangani kompatibilitas dengan berbagai versi OS
  • Mengikuti praktik terbaik kesehatan sistem
  • Mendukung tugas tidak bersamaan dan tugas periodik
  • Mendukung tugas berantai dengan input/output
  • Anda bisa menyetel batasan kapan tugas dijalankan
  • Menjamin eksekusi tugas, bahkan bila aplikasi atau perangkat dimulai ulang

Mari kita lihat contoh konkretnya di mana kita membangun pipeline tugas bersamaan yang menerapkan filter ke sebuah gambar. Hasilnya kemudian dikirim ke tugas compress dan kemudian ke tugas upload.

Kita bisa menetapkan serangkaian batasan untuk tugas-tugas ini dan menentukan kapan mereka dapat dieksekusi:



Contoh rantai tugas dengan batasan
Semua pekerja ini menetapkan urutan yang tepat: mis. kita tidak tahu urutan pemfilteran gambar, tetapi kita tahu bahwa pekerja Compress hanya akan mulai setelah semua pekerja Filter selesai.

Cara kerja penjadwal WorkManager
Untuk memastikan kompatibilitas mundur ke API level 14, WorkManager memilih cara yang tepat untuk menjadwalkan tugas latar belakang bergantung pada API level perangkat. WorkManager bisa menggunakan JobScheduler atau kombinasi dari BroadcastReceiver dan AlarmManager.



Bagaimana WorkManager menentukan penjadwal yang akan digunakan
Apakah WorkManager siap digunakan untuk produksi?

WorkManager sekarang dalam versi beta. Ini berarti bahwa tidak akan ada perubahan yang merusak API dalam revisi utama ini.

Ketika WorkManager versi stabil sudah dirilis, WorkManager akan menjadi cara yang disukai untuk menjalankan tugas latar belakang. Karena alasan ini, sekaranglah saat yang tepat untuk mulai menggunakan WorkManager dan membantu mengembangkannya!

lihat selengkap nya disini https://developers-id.googleblog.com/2019/01/memperkenalkan-workmanager.html

Monday, October 21, 2019

Data Binding Android dan Pelajaran yang Didapat

Data Binding Library (yang selanjutnya akan kami sebut ‘DB library’ dalam postingan ini) menawarkan cara yang fleksibel dan kuat untuk mengikat data ke UI Anda, tetapi seperti pepatah lama: ‘kekuatan yang besar diikuti tanggung jawab yang besar’. Hanya karena Anda menggunakan pengikatan data, bukan berarti Anda bisa menghindar dari menjadi pelaku UI yang baik.
Saya telah menggunakan pengikatan data di Android selama beberapa tahun terakhir dan postingan ini merinci beberapa hal yang telah saya pelajari selama ini.

Gunakan pengikatan standar bila memungkinkan
Adapter pengikat khusus adalah cara terbaik untuk menambahkan fungsionalitas khusus ke View dengan mudah. Seperti banyak developer, saya bertindak agak jauh dengan adapter pengikatan dan berakhir dengan class yang penuh berisi 15 adapter dengan kualitas yang berbeda-beda.
Penyebabnya adalah sejumlah adapter yang menghasilkan string terformat dan menyetelnya di TextViews. Adapter biasanya dirujuk hanya dalam satu layout:

Meskipun ini mungkin terlihat pintar, tetapi ada tiga kelemahan besar:
Sulit mengaturnya. Kecuali jika Anda adalah seorang yang sangat teratur, Anda cenderung memiliki satu file besar yang berisi semua metode adapter Anda. Antitesis yang kohesif dan terpisah.
Anda harus menggunakan instrumentasi untuk pengujian. Menurut definisi, adapter pengikatan tidak menampilkan nilai, mereka mengambil input kemudian menetapkan properti pada tampilan. Ini berarti Anda harus menggunakan instrumentasi untuk menguji logika khusus Anda, yang membuat pengujian menjadi lebih lambat dan mungkin lebih sulit dijaga.

Kode adapter pengikatan khusus (biasanya) tidak optimal. Jika Anda memperhatikan pengikatan teks bawaan [di sini], Anda akan melihat bahwa ia melakukan banyak pemeriksaan untuk menghindari pemanggilan TextView.setText(), sehingga mengefisienkan pemberian layout yang tidak terpakai. Saya jatuh ke dalam perangkap berpikir bahwa DB Library akan secara otomatis mengoptimalkan update tampilan. Dan itu benar, tetapi hanya jika Anda menggunakan adapter pengikat bawaan yang dioptimalkan dengan cermat.

Sebagai gantinya, pisahkan logika metode Anda menjadi class yang kohesif (saya menyebutnya kreator teks), kemudian teruskan ke pengikatan. Dari sana Anda bisa memanggil kreator teks dan menggunakan pengikatan tampilan bawaan: Dengan cara ini, kita mendapatkan semua efisiensi dari pengikatan bawaan, dan kita bisa dengan mudah menguji unit kode yang menciptakan string terformat.

Menjadikan adapter pengikatan khusus Anda lebih efisien
Jika Anda benar-benar perlu menggunakan adapter khusus, karena fungsionalitas yang Anda inginkan tidak tersedia, maka cobalah membuatnya seefisien mungkin. Maksud saya adalah dengan menggunakan semua optimalisasi UI Android standar: hindari memicu perubahan ukuran/layout bila memungkinkan.

Hal ini bisa hal yang sederhana seperti memeriksa apa yang sedang digunakan oleh tampilan vs. apa yang Anda setel. Berikut adalah contoh di mana kita menerapkan kembali adapter ImageView standar untuk android:drawable: Sayangnya, tampilan tidak selalu bisa mengekspos status mengenai apa yang perlu kita periksa. Berikut adalah contoh dengan setelan toggle max-lines pada TextView. Ia memfungsikan toggle dengan mengubah properti maxLines TextView, bersama dengan transisi layout tertunda.



Supaya Anda bisa tahu tentang apa yang dilakukannya
Sebelumnya, adapter pengikatan berformat sederhana dan selalu menyetel properti maxLines, bersama dengan listener klik. TextView akan selalu memicu layout ketika setMaxLines() dipanggil, yang berarti bahwa setiap kali adapter pengikatan dijalankan, layout akan terpicu.

Jadi mari kita perbaiki. Karena fungsionalitas ini sepenuhnya terpisah dari TextView (kita hanya memanggil setMaxLines() dengan nilai yang berbeda saat diklik), kita perlu menyimpan sendiri status ‘current’. Untungnya, View memberikan kita cara praktis untuk melakukannya melalui mekanisme tag. Di sini, kita hanya menyimpan nilai collapsedMaxLines yang saat ini disetel dalam tag, dan ketika adapter dijalankan, kita memanggil setMaxLines(), dll. hanya jika nilainya berbeda.

lihat selengkapnya disini https://developers-id.googleblog.com/2019/01/data-binding-pelajaran-yang-didapat.html

Sunday, October 20, 2019

Mempersiapkan aplikasi Anda untuk persyaratan 64-bit

Ditulis oleh Vlad Radu, Product Manager, Play dan Diana Wong, Product Manager, Android
CPU 64-bit memberikan pengalaman yang lebih cepat dan lebih kaya bagi pengguna Anda. Menambahkan versi 64-bit pada aplikasi akan meningkatkan kinerja, memberi jalan bagi inovasi pada masa depan, dan mempersiapkan Anda untuk perangkat dengan hardware 64-bit saja.

Kami ingin membantu Anda bersiap-siap dan memberi tahu bahwa Anda perlu waktu untuk merencanakan. Kami telah mendukung CPU 64-bit sejak Android 5.0 Lollipop, dan pada tahun 2017 kami pertama kali mengumumkan bahwa aplikasi yang menggunakan kode native harus menyediakan versi 64-bit (selain versi 32-bit). Hari ini, kami memberikan informasi dan jadwal yang lebih terperinci untuk semakin mempermudah transisi pada tahun 2019.

Persyaratan 64-bit: apa artinya bagi developer
Mulai 1 Agustus 2019:
Semua aplikasi dan update aplikasi baru yang menyertakan kode native harus menyediakan versi 64-bit selain versi 32-bit saat memublikasikan ke Google Play.

Ekstensi: Google Play akan terus menerima update 32-bit saja untuk game yang menggunakan Unity 5.6 atau versi lebih lama hingga Agustus 2021.

Mulai 1 Agustus 2021:
Google Play akan berhenti menyajikan aplikasi tanpa versi 64-bit pada perangkat berkemampuan 64-bit, yang berarti mereka tidak akan lagi tersedia di Play Store pada perangkat tersebut.
Ini termasuk game yang dibangun dengan Unity 5.6 atau versi lebih lama.

Persyaratan ini tidak berlaku untuk:
APK atau paket aplikasi yang secara eksplisit menargetkan Wear OS atau Android TV, yang merupakan platform yang saat ini tidak mendukung kode 64-bit.

APK atau paket aplikasi yang tidak didistribusikan ke perangkat yang menjalankan Android 9 Pie atau yang lebih baru.

Kami tidak mengubah kebijakan kami tentang dukungan 32-bit. Play akan terus menghadirkan aplikasi untuk perangkat 32-bit. Persyaratan ini berarti bahwa aplikasi dengan kode native 32-bit juga harus memiliki versi 64-bit tambahan.



lihat selengkap nya disini https://developers-id.googleblog.com/2019/01/mempersiapkan-aplikasi-anda-untuk.html

Saturday, October 19, 2019

Memindahkan Android Studio dan Android Emulator ke versi 64-bit

Memindahkan Android Studio dan Android Emulator ke versi 64-bit

Dengan Project Marble, tim Android Studio berfokus pada upaya untuk membuat fitur-fitur dasar dan alur Integrated Development Environment (IDE) yang solid. Kinerja adalah tenant yang mendasari dalam memberikan IDE berkualitas tinggi. Untuk tujuan ini, kami mempertajam fokus produk dan hanya akan mendukung sistem operasi 64-bit ke depan. Menggunakan Android Studio dengan sistem operasi 64-bit memungkinkan akses yang efisien ke memori, baik untuk IDE maupun Android Emulator, dan secara keseluruhan mengarah pada pengalaman pengembangan yang lebih baik. Meskipun tidak akan memengaruhi sebagian besar pengguna Android Studio, perubahan ini memang berdampak jika Anda menggunakan versi 32-bit Microsoft® Windows®. Untuk membantu transisi bagi developer yang menggunakan Microsoft Windows versi 32-bit, kami ingin memberi Anda detail tentang timeline depresiasi mendatang ditambah langkah-langkah yang harus dilakukan untuk bersiap-siap menghadapi perubahan ini.

Timeline
Untuk meminimalkan dampak perubahan ini terhadap sistem operasi 64-bit yang didukung secara eksklusif, kami pertama-tama akan menghentikan dukungan untuk versi 32-bit. Selama fase depresiasi, baik Android Studio maupun Android Emulator akan terus bekerja, tetapi produk-produknya tidak akan menerima update fitur baru. Selama masa transisi ini, Anda masih bisa mendownload produk dari situs web Android Studio. Setelah satu tahun, kami akan secara resmi mengakhiri dukungan produk dan akan menghapus link download versi 32-bit. Catatan, jika Anda sebelumnya sudah menginstal Android Studio versi 32-bit selama periode ini maka produk tersebut akan terus berfungsi, tetapi kami tidak akan menyediakan link untuk mendownload ulang produk tersebut. Tanggal untuk periode akhir dukungan dan depresiasi bisa dilihat dalam tabel di bawah ini:

Versi Produk 32-bit yang Didukung Depresiasi dari Akhir Dukungan pada
Android Studio IDE 3.6 31 Desember 2019 31 Desember 2020
Android Emulator 28.0.25 30 Juni 2019 31 Desember 2020

Keuntungan lingkungan pengembangan 64-bit
Ada beberapa keuntungan ketika kita menggunakan Android Studio versi 64-bit, yang meliputi:
Kinerja - IDE bisa bekerja lebih baik karena dapat mengakses memori lebih dari 4GB. Peningkatan memori khususnya memberikan pengalaman yang lebih baik ketika Anda mengerjakan project besar.
Dukungan Aplikasi 64-bit - Anda bisa membangun versi aplikasi 32-bit dan 64-bit bila aplikasi Anda menggunakan kode native C/C++. Pengujian pada kedua arsitektur bisa membantu Anda bersiap-siap untuk persyaratan 64-bit di Google Play yang dimulai pada 1 Agustus 2019.

Pengujian pada Emulator - Citra sistem Android Emulator 32-bit maupun 64-bit didukung oleh Android Emulator versi 64-bit. Fleksibilitas ini mempermudah pengujian aplikasi Anda di berbagai lingkungan Android dengan satu mesin pengembangan.

Langkah berikutnya
Ringkasan, sebelum mengakhiri dukungan untuk Android Studio versi 32-bit, kami ingin memberi tahu Anda terlebih dahulu, menyediakan panduan, dan memberikan waktu tunggu satu tahun untuk membantu Anda bermigrasi ke sistem operasi 64-bit. Anda masih bisa menggunakan Android Studio versi 32-bit, tetapi perlu diingat bahwa versi ini tidak akan menerima update di masa mendatang. Oleh karena itu, jika Anda ingin bermigrasi, kami sarankan Anda memulai perencanaan lebih awal sehingga Anda bisa terus mendapatkan update produk terbaru dan memanfaatkan secara maksimal peningkatan kinerja lingkungan pengembangan 64-bit.

lihat selengkap nya di https://developers-id.googleblog.com/2019/06/memindahkan-android-studio-dan-android.html