Get best of the week

Apa yang ingin Anda ketahui sebelum menulis aplikasi untuk Apple Watch: pengalaman kami

Sebuah platform yang sangat lambat menanti Anda, transisi ke kerangka kerja baru, pengujian dengan suasana khusus dan pemberitahuan dari OS "hei, gerakkan" sedetik sebelum bongkar paksa utas.


Ya, ini tangan saya yang berbulu.

Jadwal kereta api kami melayani 600 ribu orang per hari. Dan setiap tahun semakin banyak - melalui aplikasi mobile. Kami berpikir dan memutuskan untuk membuat versi untuk arloji. Masalahnya adalah kita tidak tahu berapa banyak Apple Watch yang ada di pasar Rusia, dan berapa banyak dari mereka yang naik kereta listrik. Tetapi bagaimanapun juga, penting untuk mencari tahu bagaimana melakukan ini, jadi kami mengambil dan menulis ke Apple untuk meminta statistik.

Anehnya, mereka tidak melakukannya. Kemudian mereka membantu dengan segala cara lebih jauh, tetapi di sini dengan statistik ada masalah langsung. Tidak ada yang memiliki data normal per tahun yang lalu, dan bahkan mempelajari laporan penjualan tidak membantu. Jam tangan dibawa dalam banyak cara ke "abu-abu" dan bukan dari wilayah kami pada awalnya.

Mengapa statistik? Untuk memahami berapa generasi yang ada di pasar. Pada akhirnya, kami memutuskan untuk mendukung semua perangkat.


Statistik terakhir yang kami tahu untuk 2017 terlihat seperti ini:

  • 1st gen (semua) - 57%
  • Seri 2 (semua) - 32%
  • Seri 1 (semua) - 11%

Ke depan, kami memiliki tiga bulan setelah rilis pada tahun 2019 seperti ini:

  • Apple Watch Series 3 (semua) - 36%
  • Seri 4 (semua) - 31%
  • Seri 5 (semua) - 24%
  • Gen 1 (semua) - 4,5%
  • Seri 2 (semua) - 2,5%
  • Seri 1 (semua) - 2%

Distribusi ukuran layar dari dua revisi terakhir:

  • S4 besar pada 44 mm - 58%, kecil 40 - 42%.
  • S5 besar - 60%, kecil 40%.

Model sebelumnya masih memiliki 38 mm, dalam jumlah total semua pemasangan sedikit kurang dari 20%, terutama karena S3. Omong-omong, kami membutuhkan font untuk ukuran layar yang berbeda - desainer kami membuat font yang adaptif.

Platform yang sangat lambat


Jadi, kita tampaknya tidak memiliki banyak perangkat, tetapi yang hingga 5% (seperti yang diharapkan) akan sangat tua. Jam-jam pertama umumnya dikandung, sepertinya, seperti perangkat yang menunjukkan gambar yang dihasilkan di ponsel. Kemudian muncul OS yang dikembangkan sendiri, dan dalam revisi kemudian - juga Wi-Fi dan kartu SIM.

Kartu SIM di Rusia tidak berfungsi. Mungkin, tahun ini operator akan setuju, tetapi untuk saat ini hanya ada wifi dan komunikasi melalui telepon (arloji terhubung ke iPhone melalui Bluetooth, dan kemudian menggunakan koneksi Internetnya).

Logika bekerja dengan jaringan, memori dan disk hampir sama dengan di iOS.Maksud saya, logikanya sendiri adalah umum, layanannya umum, tetapi masih ada penyergapan dengan perpustakaan - pada kenyataannya, tidak banyak orang yang mengembangkan selama berjam-jam, jadi mungkin tidak ada kerangka kerja dan alat yang populer di iOS / iPadOS. Dalam kasus kami, ini berarti kebutuhan untuk meninggalkan tumpukan perpustakaan yang kami kaitkan ke aplikasi iOS dengan gerakan tangan yang biasa.

Tanpa kecuali, semua jam tangan membuat akses disk sangat lambat dibandingkan dengan cara mereka dapat dibaca dari memori. Jika pada iPhone Anda tidak dapat benar-benar repot di mana tepatnya tabel 40 Kb berada, maka pada jam tangan sangat penting untuk menyimpannya di memori atau menerimanya melalui udara. Yang paling penting adalah tidak membaca apa pun dari disk.

Tentu saja, semakin baru jamnya, semakin cepat segalanya berubah, tetapi kami, pada kenyataannya, bekerja untuk S3 dengan dukungan untuk perangkat sebelumnya dan fitur tambahan untuk S4 dan S5.

Versi alpha dari aplikasi, yang menunjukkan rute pulang, dimuat selama berjam-jam puluhan detik. Jadwal MCC ditunjukkan selama 20 detik di 4 kereta terdekat. Masalahnya adalah di tabel membuat - terlalu banyak elemen individu. Bayangkan sebuah peramban modern yang mencoba membuat sesuatu di inti 386SX. Jadi kami punya masalah yang sama.

Secara alami, itu sebabnya dia alfa untuk menyodok dengannya. Dengan beta, kami menyebarkan beban ke utas (menangkap fitur di sepanjang waktu ketika jam mulai pada watchOS 4, titik masuk utama tidak dimulai pada arus utama). Untuk jam "lemah", jumlah sel di antarmuka terbatas.


Masing-masing diberikan sekitar satu detik.



Beberapa optimasi dari UI itu sendiri, dan terbang ke S4, dan untuk perangkat yang lebih lama harus mengurangi jumlah kereta yang ditampilkan.

Mereka menyisipkan di atas dan di bawah "tunjukkan yang berangkat" dan "tunjukkan berikutnya", dan pada orang-orang pilihan - "tunjukkan semua". Karena jadwal ini sering berubah, maka sering kali perlu digambar ulang: kita berbicara tentang situasi ketika komposisi tabel berubah baik karena kereta yang berangkat, atau karena perubahan jadwal (kami menunjukkan pergerakan waktu-nyata, yaitu, kami tahu di mana tepatnya masing-masing khusus melatih sebenarnya, dan bagaimana hal itu akan mempengaruhi semua stasiun lebih lanjut di sepanjang rute).

Seringkali ada situasi ketika data menjadi usang satu detik setelah permintaan. Dengan pendekatan dasar, seluruh tabel diputar, ini adalah cara standar untuk iOS. Di sana, pembaruan umumnya tidak terlihat. Dan di sini mereka telah melakukan banyak omong kosong berdasarkan pemrosesan array yang masuk, yang mem-parsing data terlebih dahulu, kemudian membuat diff, lalu menemukan elemen UI yang dapat diubah tanpa menyentuh yang lainnya, dan kemudian hanya memperbaruinya. Tidak ada pustaka yang cocok untuk solusi lengkap pada WatchOS, tetapi ada Differentiator Kit, yang menurut array data dengan markup, memberikan daftar bagaimana dan apa yang telah berubah oleh indeks. Mereka menulis kode mereka di sekitarnya dan meletakkannya di semua tabel. Ini memberi peningkatan pembaruan kinerja.

Secara umum, kereta N terdekat ditampilkan dengan cepat, dan jika Anda ingin menunggu, tetapi ingin gambar yang lengkap, Anda dapat mengklik "tampilkan semua".

Seperti yang saya katakan, tombol di arloji itu besar, tetapi lambat. Pertama, kami menggunakan satu set standar perpustakaan iOS yang bekerja melalui disk. Kami mendapat jadwal, merekamnya di disk, layanan yang diminta, mengambilnya dari disk, melepaskannya ke layar. Ternyata, Anda perlu menyimpan cache dalam memori. Namun kita terbiasa menyimpan semua status pekerjaan pengguna ke disk, dan kemudian membacanya dari sana - kita hanya perlu merekam dan menyimpan semua yang kita bisa dalam memori.



Mengapa perekaman konstan diperlukan? Karena jika pengguna mengganti aplikasi, pembongkaran terjadi hampir secara instan. Anda biasanya tidak punya waktu untuk menulis apa pun ke disk pengereman, jadi Anda harus melakukannya terus-menerus dan berulang saat pengguna bekerja.

Dan kemudian kita mendekati penyergapan berikutnya.

Konservasi Energi Manik


Baterai di arloji ini kecil, dan seluruh sistem operasi dipertajam untuk menghemat daya sebanyak mungkin. Dalam praktiknya, ini mungkin berarti bahwa pengguna melakukan hal berikut:

  1. Mulai mengunduh sesuatu (misalnya, jadwal lengkap)
  2. Menurunkan tangan
  3. Sedang menunggu
  4. Mengangkat tangan untuk melihat apa yang dimuat

Bahkan, yang berikut ini terjadi:

  1. Pengguna mulai mengunduh jadwal lengkap
  2. Menurunkan tangan
  3. Jam tangan memahami bahwa mereka tidak bekerja dengan mereka dan memasukkan proses ke analog hybernate.
  4. Pengguna menunggu, lalu mengangkat tangannya untuk melihat hasilnya.
  5. Pada saat pendakian, jam tangan memahami bahwa mereka terus bekerja dengan mereka, bangun dan bangun proses.
  6. Pengguna melihat awal dari indikator pengunduhan.

Pada saat yang sama, dari sudut pandang utas, ini bisa berupa waktu yang tepat atau "detik yang sangat lama" - jika Anda menulis kode pada waktu habis, Anda dapat tiba-tiba menangkap bahkan satu tahun di mana setengah detik telah menunggu. Karena itu, ingatlah bahwa waktu itu relatif.

Proses kebangkitan mengancam Anda dengan proses debugging yang panjang - di sana Anda dapat menangkap kerusakan pada fakta bahwa tempat tersebut dikosongkan, atau sesuatu yang menarik terjadi.

Proses jatuh tertidur dapat berubah menjadi proses pembongkaran (tanpa terbangun), jadi Anda perlu menulis beberapa hal ke disk. OS memberitahu thread "Pergi ke Latar Belakang" dan memanggil metode yang sesuai. Biasanya Anda memiliki sekitar satu detik untuk dengan cepat keluar dan membuang di latar belakang. Ketika pengguna melakukan ini saat menulis ke disk (yang, saya ingat, sangat lambat pada perangkat hingga S4), perekaman mungkin tidak terjadi. Untuk melakukan ini, Anda harus masuk ke mode "operasi penting" dan, dengan bantuan beberapa panggilan khusus, pertahankan utas "sadar". Untuk melakukan ini, Anda memerlukan pawang terpisah yang menanyakan proses perekaman kapan akan berakhir, dan kemudian melepaskan utas untuk tidur.

Arsitektur


Aplikasi pertama kami pada tahun 2017 hanya kosong, mampu menunjukkan jadwal yang dihasilkan pada ponsel. Itu digunakan untuk menunjukkan data untuk kereta jarak jauh di trek, mobil dan tempat.

Versi modern untuk kereta adalah "dewasa" dan otonom, artinya dapat hidup kapan saja tanpa ponsel. Bahkan sejak saat pemasangan (meskipun cara biasa aplikasi masuk ke arloji adalah melalui telepon, dan pada titik ini sangat nyaman untuk menyalin data profil dan semua rute yang dipilih dari telepon).

Arsitektur pada jam tangan mungkin yang paling modern dalam pola iOS. Redux bukan masalah. Kami, seperti dalam aplikasi "besar", menggunakan mesin negara. MVC standarnya adalah ini: ada model di satu sisi, ada pandangan untuk model ini, di tengah-tengah controller. Pengontrol mengambil data dari model, mengonversi, menampilkan di layar. Dalam arah yang berlawanan, controller mendengarkan pesan tampilan dan menyediakan data ke model. Berdasarkan pola ini, banyak jenis arsitektur telah dibuat.

Kami memiliki kondisi tempat peristiwa dapat terbang dan mengubahnya. Efek samping, yang melakukan pekerjaan yang bermanfaat, dapat berangkat dari negara. Dari hasil ini, peristiwa terbang ke negara. Keadaan penuh aplikasi disimpan dalam cerita, seperti satu titik kebenaran. Negara dapat dipecah-pecah dan dibagi-bagi, tetapi bagaimanapun, ia menyimpan set data lengkap. Implementasi spesifik arsitektur tergantung pada agama, kami memiliki RXFeedback.

Mesin negara sangat baik ditutupi oleh tes. Ini menghemat banyak waktu hanya pada jam tangan, karena pengujian tidak dapat dilakukan di dalam jam tangan itu sendiri. Ini bukan iPhone untuk Anda. Di sini Anda perlu melakukan ini:

  1. Bangun aplikasi pada emulator dan lihat.
  2. . , . id Xcode .




Saya menggunakan S4 dan S1 untuk pengujian. Karena banyak hal yang sangat sulit untuk diperiksa pada arloji itu sendiri, ternyata sangat nyaman untuk mengisolasi keadaan tertentu (keadaan), mentransfernya ke komponen lain dan sudah ada pengujian dengan semua pihak.

Xcode kesepuluh (yang sebelum Oktober 2019) senang karena suatu alasan ketika aplikasi dimulai pada jam, itu berhenti bekerja di simulator. Diputuskan dengan memotong pembersih perdagangan, jika ada yang tertarik.

Dengan demikian, ketika menyusun target dengan status khusus dan dengan logika umum (ada banyak dari mereka), Anda harus membuatnya kompatibel dengan jam. Kami secara tidak sengaja mengaitkan UIKit beberapa kali, dan ini adalah kerangka UI ponsel, tidak didukung pada jam. Jika Anda secara tidak sengaja mengambil dalam rilis - perpustakaan tidak akan terhubung.

Otonomi


Kasing penggunaan dasar - pengguna memiliki arloji dan telepon. Dia secara teratur menyatukan mereka, dan arloji dapat menggunakan Internet dari telepon.



Dengan rilis jam tangan baru, dimungkinkan untuk menggunakan Wi-Fi Anda sendiri dan kartu SIM jam Anda sendiri (ada e-sim bawaan).

Tugas kami adalah untuk menyinkronkan favorit antara dua aplikasi (di telepon dan jam tangan). Setiap kali kita mulai, kita mencoba membaca kebenaran terakhir, dan setiap kali kita mengubah daftar, kita mencoba untuk segera menemukan perangkat kedua dan memberitahunya tentang hal itu. Ternyata, jelas, tidak selalu, oleh karena itu, jika memungkinkan, kami menyinkronkan saat startup. Jika ada dua favorit berbeda yang dihadapkan dengan konflik, kami menganggapnya lebih akurat apa yang ada di telepon dan kami menyelesaikan konflik yang menguntungkannya.

Kalau tidak, aplikasi tidak terhubung ke telepon. Cache ada di dalam, permintaan ke jaringan dikirim dari jam (jika mungkin), jika tidak, melalui jembatan melalui telepon. Akibatnya, Anda dapat menggunakannya secara otonom selama yang Anda inginkan, tetapi Anda hanya perlu menginstal aplikasi untuk pertama kalinya (versi kami tidak mendukung pemasangan dari jam langsung dari aplikasi). Setelah itu, Anda bisa melupakan sinkronisasi, jika mau. Sebelum menontonOS 2, skema aplikasi yang biasa adalah segala sesuatu dihitung dan dilakukan di telepon, dan jam hanya memberikan hasil.

Total


Aplikasi dasar untuk iOS di sini . Aplikasi arloji dipasangkan dengannya. Aplikasi ini menggunakan satu versi rilis, tetapi pada perangkat tertentu itu menyesuaikan dengan kecepatan dan menyesuaikan antarmuka dengan ukuran layar. Otorisasi pertama ketika menginstal melalui telepon, di tempat yang sama, menyalin favorit dan rute yang sering. Sinkronisasi lebih lanjut atau keberadaan otonom. Geolokasi dari telepon (ini diperlukan untuk memahami apakah Anda berada di Moskow atau dari Moskow, jika Anda tidak mengizinkan geo atau tidak, itu adalah permintaan pagi yang berorientasi waktu dan membalikkan). Ada instalasi sebanyak yang diharapkan (kami memperhitungkan bahwa tidak ada banyak jam di Rusia, dan penggunanya ada di kereta listrik). Dilihat oleh ulasan, pengguna aplikasi di arloji senang melihat jadwal mereka di eskalator.

More articles:


All Articles