Розробка і паблішинг для різних мобільних платформ: нюанси і проблеми

Сердюк Павло. Mobile-developer, Team Lead з 5-річним досвідом

Перше знайомство• Перший мобільний застосунок на платформі WinPhone (2010 р.)• Досвід перед тим : .Net Web, backend, desktop

Homecare mobile

• Переведення десктопного аплікейшену на мобільну платформу

• Проект перед тим йшов 11 років (11, Карл!)• Перший етап – підготовка прототипу (6 міс)• Наступний етап – реалізація решти

функціоналу (багато місяців )

Проблеми з оптимізацією• OnPropertyChanged • Свої базові ViewModel, власні компоненти, купа сторінок• Економилось буквально на всьому ….

Перекомпіляція базових компонент

• Потрібне те саме, тільки з “перламутровими гудзиками” – вимога замовника

• Антипаттерн Adam object в дії – це повний капець для тестерів

Інші проблеми

• Light / Black mode• Проблеми з локальним кешем– Офлайн режим – це біль кожного мобайл дева– Складна логіка вирішення конфліктів даних– Синхронізація 200 працівників починається о

9.00• Поява нової версії – Windows phone 7.5

(нові розширення екрану)

Кінець проекту

• Акції компанії пішли вниз • Але до завершення апплікейшена було ще

далеко

Висновок 1. Мобільні застосунки повинні бути невеликими

• Користувач мобільних девайсів хоче “швидко отримати бажане” (див. рис.)

• Enterprise app рідко коли “вистрілює” на мобільних платформах, бо самі платформи часто не розраховані на великі аплікейшени

• Тому мобільні проекти ідеально підходять людям, які довго не можуть бути на одному проекті

Стартап

• “Еко” гра• Реалізація– Кілька рівнів

• Accelerator для керування

• Складна логіка

Паблішинг

• Паблішинг за допомогою “Dev rain solutions” (довго шукали, хто б це міг зробити)– Ліба для статистики

• Рекомендували in app-purshase – Ми реалізували фрішну і повну платну версію

• Завертали з маркету– Найбільше завертали фрішну версію– Кнопка “Back”– Музика (якщо вже користувач запустив якийсь плейер)– Маніфест (категорія – 7 та 8 версія відрізнялись)

А були такі мрії …• Неправильно обрана платформа• Неправильно обраний жанр• Занадто велика складність

Висновок 2. Перейти на Android та IoS

• Складно починати спочатку, але з Windows Phone не склалось

IoS SMS confirmation

• На App store не могли зробити перевірку надсилання SMS

• Були підключені локальні сервіси для посилання – але для Америки то, звісно, не спрацювало (((

• Перевірка локалізації визначила оператора, але тоді потрібно розширювати вимоги аплікейшена

• У програмі існувала перевірка на локалізацію по місту – довелесь вносити гидкий хардкод (

Перехід на Android• Вічне клієнтське – а потім ми хочем те саме, але під IoS• Досвідчені замовники хотіли 2 нативних продукта, хоча

більшість розривалась між бажанням економії та якості• Основна проблема з Андроїд – клієнти мають малий

бюджет• Основна проблема з IoS – сеніорів під IoS дуже важко

знайти

HR найшла IoS Сеніора

Xamarin

• Android має обрізану Java, Xamarin ще більше її ріже

• XForms – поки-що досить недозріла технологія

• MVVM Cross – ліпше, але хотілось би більшого

• Погана підтримка

Xamarin. Мультиплатформенність• Intellisense не працює • Design mode не працює• Xamarin Studio – глючна тулза

MVVM Cross теж не ідеальний • Intent не працює (• Resource

Можливості трохи не ті (

Плюси

• Написання коду на C# • Частину коду можна таки викорисати на

кілька платформ– Не рекомедується при складному UI

• Хороші інструменти: – Xamarin Android Player– Xamarin.UITest + Xamarin Test Cloud– Sketches

Дякую !