#monodroid

Bardzo często Klienci którzy chcą stworzyć swoją pierwszą aplikację mobilną są zaskoczeni wysokością kosztów jakie trzeba ponieść i nie za bardzo rozumieją dlaczego te koszty są tak wysokie. Spróbojemy rozebrać to wszystko na czynniki pierwsze, aby pokazać gdzie powstają koszty i czy naprawdę musi być tak drogo (będziemy dokonywać pewnych uproszczeń i uogólnień, które mamy nadzieję osoby techniczne nie będą razić za bardzo).

  Zaczniemy od małej scenki z życia:

„Klient: chciałbym aplikację mobilną na iOS i Android

Kaizen: OK – super, czy ma być wersja na tablety dedykowana tez?

Klient: tak, oczywiście

Kaizen: OK – a możliwość obracania aplikacji (układ pionowy i poziomy)

Klient: tak, tak

Kaizen: OK – a ... ....

....

Klient: to ile to będzie kosztować?

Kaizen: no tak z minimum 20tys zł.

Klient: AAAAAAAAAAAAAAAaaaaaaa!”

  Krok pierwszy  – Technologia:

W chwili obecnej, aby stworzyć aplikację mobilną mamy do wyboru 3 podstawowe kierunki:

- aplikacja natywna: stworzona w technologii dedykowanej dla danej platformy (w przypadku iOS będzie to Objective-C, dla Android Java, dla Windows Phone .NET),

- aplikacja ‘pół-natywna’ : dzięki wykrozystaniu framework’ów takich jak Xamarin można stworzyć aplikację natywną w technologii .NET, gdzie kod będzie współdzielony pomiędzy wszystkie platformy,

- aplikacja HTML: aplikacja stworzona za pomocą języka HTML i JavaScript.

  Jakie są podstawowe różnice:

- wydajność: aplikacje natywne i pół-natywne są dużo wydajniejsze niż aplikacje stworzone za pomocą języka HTML,

- możliwości: analogicznie j.w.

- pracochłonność: koszt stworzenia aplikacji natywnych jest największy i wymaga najliczniejszego zespołu (min. 1 programisty dla każdej platformy), aplikacje pół-natywne są tańsze (wystarczy 1 programista), ale ciągle wymagają większych nakładów pracy niż aplikacje stworzone w HTML’u które są najtańsze..

  Krok drugi – layout aplikacji:

Aby aplikacja wyglądała dla odbiorców atrakcyjnie konieczne jest przygotowanej przez grafika dedykowanego layoutu. I teraz pół biedy jeśli chodzi o aplikację na jedną platformę, tylko dla smartphonów i układu pionowego.. ale co się dzieje jeśli klient chce tego więcej?

Przyjmijmy koszt stworzenia przez grafika jednego ekranu za X. Jeśli klient chce wersję i na smartphony i na tablety to koszt wzrasta o średnio 50% (nie da się wykorzystać layoutu ze smartphonów wprost na tablety – trzeba to inaczej zaprojektować aby wyglądało atrakcyjnie). Tak samo jeśli klient chciałby wsparcia dla rotacji urządzenia – tutaj też wymagane jest przeprojektowanie layoutu i koszty znowu idą w górę o 50%. A co jeśli ma być kilka platform? Czy to iOS, czy Android, czy Windows Phone mają swoje rozwiązania jeśli chodzi o nawigację, czy komunikację z użytkownikiem – co wymaga dopasowania projektu graficznego dla każdej platformy.

Podsumujmy:

- czas bazowy dla ekranu X

- wersja dla tabletów i smartphonów – 1,5 X

- wersja pionowa i pozioma – 2,25 X

- wersja dla iOS, Android i Windows Phone – 3,37 X

Oczywiście layout który grafik zaprojektu programista musi jeszcze zaimplementować, i tutaj jest jeszcze mniej różowo bo layout dla poszczególnych platform w przypadku rozwiązań natywnych tworzy się od zera (każda platforma ma swoje środowisko graficzne) - tutaj szczególnie bolesne jest to w przypadku Android’a, który występuje w milionach różnych wersji, gdzie każda ma inną rozdzielczość i gęstość (density) ekranu.

  Krok trzeci – co z tym zrobić?

Wierzymy w filozofię Lean Startup i MVP (Minimum Viable Product) – dlatego naszych Klientów zachęcamy do zaczęcia swojej przygody z aplikacjami mobilnymi od prostej wersji, tylko na jedną platformę, w jednym układzie graficznym i tylko na tablety lub tylko na smartphony.. dlaczego tak? Załóżmy, że stworzyliśmy aplikację na wszystkie platformy i możliwe warianty wydając na to np. 100tys złotych. Udostępniamy ją użytkownikom końcowym gdzie okazuje się, że oczekiwania co do aplikacji jednak były inne i teraz, aby to wszystko przerobić potrzebujemy wydać dodatkowe 50tys na poprawki....

A co jeśli zaczelibyśmy od prostej wersji na iPhone za 10tys? Pierwsi użytkownicy pozwoliliby nam wypracować właściwą wizję aplikacji i określi jakie jej warianty faktycznie potrzebujemy? (bo np. okaże się, że tak de facto wcale wersja na tablety nie jest potrzebna, 90% naszych klientów ma iPhone i nie potrzeba wersji Androidowej). Koszt finalny mógłby spaść do 50tys zamiast 150tys..

  Podsumowując

Easy way to Install a compiled Android APK into your Android Emulator. This will work with the emulator that comes with Mono for Android (Xamarin) which works with Visual Studio.

http://apkinstaller.com/downloads.html

Preparing Package for Android Marketplace

SRC: http://mono-android.net/index.php?title=Documentation/Guides/Preparing_Package_for_Android_Marketplace&highlight=signFrom $1

We have highlighted your search term sign for you. If you'd like to remove the search term, click here.

Table of contents

Once you've fully developed and tested your application, it's time to create a package you can upload to the Android Market.

In order for the Android Market to accept your application, it must define an application level icon. Ensure a line like this exists in your AndroidManifest.xml:

<application android:label="MyApplication" android:icon="@drawable/icon">

A future release will provide better support for setting this.

Step 1 - Change to Release Mode

By default, Debug mode uses the Mono shared runtime to make repeated deploying and testing quick, however you want your application to be fully self contained. Release mode turns off the shared runtime and turns on linking so that your application only ships the pieces of MonoDroid that it needs.

Next, check the Mono Android Options tab in your property pages to ensure that the shared runtime is turned off and linking (SDK Only or SDK and User Assemblies) is turned on.

Step 2 - Test in Release Mode

Turning on linking can sometime have unintended side effects, so you need to fully test your application in Release mode.

Linking Description

Step 3 - Create A Market Private Keystore

You only need to do this step once. You should always use the same key, so make sure you don't lose it. If you lose it, you will not be able to make updates to your application on the Market, you will have to remove your application and resubmit it as a new application.

Android's Private Key Documentation

Basically, you need to find "keytool" in the Java SDK, and use this command:

keytool -genkey -v -keystore <my-keystore-name>.keystore -alias <key-name> -keyalg RSA -keysize 2048 -validity 10000

Fill in <my-keystore-name> and <key-name> with your desired names.

The will produce a file containing you key called <my-keystore-name>.keystore

Step 4 - Sign the Package

There are two ways to sign the package, depending on how you want to manage the keystore. By default, Mono for Android builds will generate a debug keystore, which can't be used for Android Market deployment. If you prefer, you can elect to use a different keystore for all packaging operations.

Permanently Use A Different Keystore

If you would like to always use the keystore created in Step (3), you can alter your Project.csproj file to contain signing information:

view plaincopy to clipboardprint?

<PropertyGroup>

<AndroidKeyStore>True</AndroidKeyStore>

<AndroidSigningKeyStore>public.keystore</AndroidSigningKeyStore>

<AndroidSigningStorePass>public</AndroidSigningStorePass>

<AndroidSigningKeyAlias>public</AndroidSigningKeyAlias>

<AndroidSigningKeyPass>public</AndroidSigningKeyPass>

</PropertyGroup>

<PropertyGroup> <AndroidKeyStore>True</AndroidKeyStore> <AndroidSigningKeyStore>public.keystore</AndroidSigningKeyStore> <AndroidSigningStorePass>public</AndroidSigningStorePass> <AndroidSigningKeyAlias>public</AndroidSigningKeyAlias> <AndroidSigningKeyPass>public</AndroidSigningKeyPass> </PropertyGroup>

Alter the AndroidSigningKeyStore, AndroidSigningStorePass, AndroidSigningKeyAlias, and AndroidSigningKeyPass element values as appropriate for your deployment.

If you just want to use a specific keystore for Release builds, and/or use a different keystore for Debug builds, you can use MSBuilds Condition attribute:

view plaincopy to clipboardprint?

<PropertyGroup Condition="'$(Configuration)' == 'Release'">

<AndroidKeyStore>True</AndroidKeyStore>

<AndroidSigningKeyStore>public.keystore</AndroidSigningKeyStore>

<AndroidSigningStorePass>public</AndroidSigningStorePass>

<AndroidSigningKeyAlias>public</AndroidSigningKeyAlias>

<AndroidSigningKeyPass>public</AndroidSigningKeyPass>

</PropertyGroup>

<PropertyGroup Condition="'$(Configuration)' == 'Release'"> <AndroidKeyStore>True</AndroidKeyStore> <AndroidSigningKeyStore>public.keystore</AndroidSigningKeyStore> <AndroidSigningStorePass>public</AndroidSigningStorePass> <AndroidSigningKeyAlias>public</AndroidSigningKeyAlias> <AndroidSigningKeyPass>public</AndroidSigningKeyPass> </PropertyGroup>

Manually use a different Keystore

Manually using a different keystore currently requires:

Locating the unsigned package.

Using jarsigner to sign the package with the alternate keystore

Aligning the package

Step A - Locating the Unsigned Package

Make sure you've build and deployed your final package (.apk) in Release mode (the package gets built when you deploy), then you can find the package in your \bin\Release folder.

Note that you do not want the "-Signed" one. This one is signed with a debug key for you to deploy to your device for testing. You want the unsigned one so you can sign it with your Marketplace key.

Step B - Sign the Package

Once you have your key created, you are ready to sign your package for the Marketplace.

Android's Package Signing Documentation

You need to find the "jarsigner" tool in the Java SDK, and use this command:

jarsigner -verbose -keystore <my-keystore-name>.keystore <package .apk> <key-name>

The package is signed in place, so it is the same package, not a new one. To ensure it is signed correctly, you can run:

jarsigner -verify <package .apk>

Step C - Align the Package

The final step in preparing your package for the Marketplace is to align the package. This is a performance optimization to help Android load your application faster.

Android's Aligning Documentation

You need to find the "zipalign" tool in the Android SDK, and use this command:

zipalign -v 4 <package .apk> <final package name>.apk

Step 5 - Upload to Android Marketplace

You application is now fully packaged and ready to be uploaded to the Android Marketplace!