On your marks for the BlackBerry Port-a-thon

portathon

New Year’s greetings all. Eleven days into what promises to be a great year, I believe we have our development hats on and the holiday ones off :-).

Exciting times are here once again with yet another port-a-thon by you-know-who! Yes folks, the same guyz who perhaps coined the term port-a-thon are at it again! RIM, makers of the BlackBerry will be commencing a dual 36 hours port-a-thon today. The events start at 6pm local time, today (January 11) and runs through Saturday January 12 to 6pm Sunday, January 13.

Having partaken in the last port-a-thon, I find that a bit of recap is a good way to start. In brief, the last event which ran from December 14 to 16, 2012 had an average of 113 app submissions per hour from about 63 countries over the 36 hours period. This is according to a report sent to me by RIM.

This one though is a double combo in that RIM plans to run two port-a-thons simultaneously.

-          One is the Android Port-a-thon (http://devblog.blackberry.com/2012/12/the-android-port-a-thon-for-blackberry-10-is-here/?RMID=B2B_20130108_Portathon_Invite&RRID=ABCDEFGHIJKLMNOP1234567890123456) and it’s targeted at Android developers with existing Android apps.

-          The other is the Community Port-a-thon (http://devblog.blackberry.com/2012/12/blackberry-10-community-port-a-thon/?RMID=B2B_20130108_Portathon_Invite&RRID=ABCDEFGHIJKLMNOP1234567890123456) and it’s targeted at developers with apps built using different platforms like appcelerator, AIR, QT, Sencha, PhoneGap, Marmalade, JQuery etc.

As with previous port-a-thons, RIM’s technical gurus will be on hand to guide you throughout the event in case you run into any difficulties.

Below, I share my thoughts on why I think every app developer should attempt to partake in the port-a-thon.

Much as has been said about the market potential for RIM in Nigeria, it is not enough to be consumers of both hardware and software. Rather, we should play in a space that’s more practically possible for us vis-à-vis contents/apps creation. It is widely acknowledged that none knows our market more than we do hence, local contents that best meet the needs of our market can be better developed by us.

What more, there are incentives for every app submitted and approved. But beyond the incentives, I think developers ought to explore this option to get their great apps into the hands of those who matter; the end users. The benefits are obvious depending on your objectives. At Genii Games, it’s one that surely serves our pilot objectives and the result is one that is itself proving useful given the feedback already trickling in from approved apps. Case in point, it serves our interest in the grand scheme of what our apps are meant for. Even if your app was built to prove a personal feat, it still serves a good point to get the views of its end users. Even more, getting approved clearly justifies your app as one that meets something close to a global standard given the scrutiny that RIM does before approving of any app. I touched on the latter in my last post (http://bbdevsng.wordpress.com/2012/12/28/app-stores-contrasts-features-and-comparisons-i/).

Another reason is for us as a community to demonstrate our competence to RIM itself thus, giving voice to future demands like payment issues which they can better champion for us before the powers that be (Telcos).
I have heard arguments across different quarters ranging from RIM’s market struggles amongst its competitors to the absence of guarantees for the OS10’s success. In my view and wearing the hat of a nerd, these should not concern us at least primarily. Here’s one reason. I know my apps are mine without any exclusivity to any platform. Two, my objectives in this case are better served by porting my app to as many platforms as support them hence, I have nothing to lose. Besides, while mainstream media about RIM provides us with uncertainty, it also provides us with adventure and excitement. So dudes, you never know.

For all the excuses not to be a part of this exciting event, I find RIM’s energy unbelievably inspiring. I mean if a seemingly troubled company can be this excited about its forthcoming release enough to rally developers with different skill set and across different boundaries then I want to be a part of that organization in my own way.

To cap things up, we are a few weeks from the official release of the OS 10 and these events spell good forms of proactive approach towards launching our apps out with the release come January 30.

So folks, there you have it. Check the links provided above, register and get porting. See you on the other side :-)

Adebayo Adegbembo

t| @technobayo
e| bayo@geniigames.com
w| http://www.geniigames.com

App Stores: contrasts, features and comparisons I

appstores

Howdy all? How’s the holiday coming along? Trust great. This holiday notwithstanding for some of us, vague is perhaps the word that best suffices for the line between work and play for obvious reasons. Even more, the vagueness of the term work-hours means we jump across tinkering with codes, key-frames to writing and resting.

And so it was that yours truly woke up this holiday morning to news from RIM that an app I’d submitted to the app world over 2 weeks ago had just been approved. Good news especially coming a day after the Samsung app store turned down one of my apps. Riding on these recent events, I decided to share my musings concerning my experiences across the three major app distributors namely, BlackBerry App world, Samsung App Store and Google Play.

But first, a caveat: these are the sole expressions of this writer and not those of my employers/supervisors (site admin). Also, it is not meant as an endorsement of any mentioned parties. *big grin*

To better organize my muse, I categorize as follows.

Time

My starting point in the world of app development commenced with what was then known as the Google Market. If there was any fascination with the distribution platform besides the number of apps on parade then it was surely the ease with which the distribution process occurred.

The pace at which apps are reviewed and put up for distribution on the various app stores vary. With close to half-a-dozen apps and dozens more updates submitted to the store, I can clearly state that Google Play spends the minimum of times in getting apps approved, reviewed and/or updated. Practically, I’ve had my apps appear on the store few hours after submission.

On the part of Samsung apps, it takes about a week from submission to get an approval or rejection. This is given the pre-certification process that includes testing across various devices.

With the BlackBerry app world, it took me about 2 weeks to get one app approved while another came just under a week. In the latter case, perhaps due to its submission during the recent global port-a-thon. Fellow developers have also recounted the waiting experience to me. Given the views of these developers who have had their apps rejected or approved, the process is a thorough one similar to that of Samsung. As of this writing though, a third app is in its 3rd week of being approved.

Another factor that hastens up the process is the assets required. With Google Play, there are less assets and details to upload and fill in. Also, the process is a one-paged one that requires little or no cross-paged navigation. With the BlackBerry app world, it’s a pretty relative lengthy process that includes navigations, progress bars etc. Samsung’s is relatively faster though not as fast as Google Play’s in that its process includes little navigations and screens to deal with.

Vetting Process

While the pace at which Google Play has your app up and running on the app store is a plus, it does however leave little in doubt as to its method of approval. Case in point, its system of approving apps can be termed loose given a non-working app can scale through the process. In my experience, there is nothing to demonstrate that any form of testing is carried out on the apps. Though for obvious reasons given the multitude of OEMs it serves, it is still a downside that having my app on Google Play does not necessarily translate to having a standard working app as it is best left to its users.

In Samsung’s case, the length of time it takes in reviewing one’s app is made up for by the outcome. As I’ve had over time, it is on record that Samsung goes in depth to thoroughly review and test any app submitted to its store. Not once or twice have I had my apps rejected along with tens of megabytes load of report containing videos, html files etc to explain the reasons. Yes, the guys at Samsung are that thorough! Given the variety of device that the brand offers, it tests as far and wide as possible to make sure apps are well suited to run on them. Though I’m often frustrated by the process especially when it turns up rejected as I experienced with an app yesterday, Samsung’s report is so detailed that you have a proper picture of what went wrong and needs be fixed in other to scale through the submission process.

My experience with the BlackBerry app world in this regard is fairly new but with three apps (2 approved and 1 pending), I find that their process is also very thorough. First, it takes a fair amount of time to get an app approved as I had with one of my approved apps. However, discussions with fellow developers indicate a process that involves proper testing and if any issues, a report explaining what needs be done.

Conclusion

While the pace at which Google Play serves up its apps makes for ease of updates and distribution, the reality of the global app market space means developers need a means of ensuring our apps do indeed meet required standards. For the avoidance of doubt, this reality is one that does not clearly differentiate local apps from foreign apps given the universality of the skills required. On the local front, with the challenges of utilizing virtual testing labs like Samsung’s, the thoroughness that goes into reviewing apps by the likes of RIM and Samsung when submitted is well appreciated.

Thus, the anxiety that greets the waiting process in the case of the BlackBerry App world and Samsung are clearly justified by the resulting outcome.

So there you have it, my sole thoughts. Be glad to hear your side of the story with regards to your experience distributing apps on any platform.

I’ll run a sequel to this piece in a next post touching on contexts like monetization, Awareness etc.

Until then, happy development.

Adebayo Adegbembo

t| @technobayo
e| bayo@geniigames.com
w| http://www.geniigames.com

Deploying Adobe AIR apps to the BB 10 ALPHA DEVICE: novice to ninja!

air

Yipee! These are exciting times for some of us developers. Why not? RIM, the company behind the most popular Smartphone in the Nigerian market is weeks away from releasing its much talked about OS 10. As developers, we all have our personal reasons for the excitement. For the most part, it offers us even more avenue to get our apps into the hands of our target audience. On my part, the multi-faceted support it provides for developing or porting of apps namely WebWorks, java, Adobe AIR etc is such that some of us need not embark on a new learning curve to get on the platform.

For Adobe AIR developers or those looking to capitalize on their Flash or ActionScript 3.0 skills for the BB10 platform, this post should get you started.

Some weeks ago, I had issues deploying my AIR apps to the BB 10 device and posted on the forum. Thanks to Michael Weitzel plus a couple of online resources, I had it figured out. Thus, I’ll be sharing with you an aggregated guide on how to port your AIR built app for the BB 10.

Which leads us to my introductory topic …

Deploying Adobe AIR apps to the BB 10 ALPHA DEVICE: novice to ninja!

Traditionally, I use the Adobe Flash IDE for my development so we’ll use a simple helloworld project as test. Here’s all you need to get started.

-           Download the AIR SDK from https://developer.blackberry.com/air/download/.

-          Also, open up your command line. Yeah I know, that black screen that some of us never want to deal with. Well, I find it’s a handy companion in my case so relax.

STEP 1: Install the BlackBerry OS 10 SDK for AIR. Be sure to note the folder path where it is being stored during installation. This’ll come in handy during stage 2.

STEP 2: Set the path to the bin. This is to allow you call the tools for the packaging, signing etc from the command line without having to type out the full path where it is stored.

For Windows user,

-          Right-click on “My Computer”, Select Properties.

-          From the window that opens, select “Advanced System Settings” at the top left.

-          Next, select “Advanced” from the tabbed menu that opens.

-          From there, select “Environment Variables” then “Path”.

-          Next, click the “Edit” button.

-          Now, go into the folder where you saved your package during installation. Locate the ‘ bin’ folder and copy off the path at the top. In my case, it was “C:\Users\GETTO\Documents\BB_10_Tools\blackberry-tablet-sdk-3.0.0\bin”. Be sure to change the path to reflect yours. Before pasting, make sure the last line on the existing line has a semi-colon (;) else, append it to it then paste. Finish by adding a semi-colon (;) then select OK.

To test for its success, open your Command line. You may have to exit and re-open if it was open during the previous process.

Type blackberry-airpackager and select the ‘Enter’ key on your keyboard. You should see a bunch of lines spill out.

Bingo! Stage 1 scaled. Grab a cup of water before we proceed.

STEP 3a: Registrations

For BlackBerry developers, testing your app on the device requires two processes. One, you can either request a signing key from RIM or two, obtain a debug token. In my case, I went with the former since I’d still have to do so for publication to the BlackBerry App world.  Know that “an internet” connection is required for this process.

The following steps are critical to the signing process so do please proceed carefully. The beauty is that you only have to complete it once. Let’s get on with it

-          First, request for a signing key from RIM by following the link https://www.blackberry.com/SignedKeys/codesigning.html

While filling the form, please note the PIN you enter as it’ll be used afterwards. This PIN is not your BB PIN. Rather, a sort of password that you should provide.

-          Once successful, you’ll get an email asking you to wait for some hours. Notwithstanding, it arrives in your email much lesser than say 2 hours. In the meantime, ensure you check your SPAM folder too.

-          The file comes as an attachment with a .CSJ format. It’s named something like client-RDK-1234****.csj

-          Download it and note the path where it is stored

STEP 3b: Creating the CSK file

-          Next, we create what is called a CSK file by typing the following into your command line making sure to use your desired password in the text marked in red. I find that it helps to use the same password (PIN) used while requesting for the signing keys in Step 3a above. Since there is nothing stopping you from doing so, I recommend you use same password.

Blackberry-signer –csksetup –cskpass yourcskpassword

You should get a prompt saying CSK file created

STEP 3c: Register your .csj file with the RIM server

-          Now, type the following into your command line

Blackberry-signer –register –csjpin  ThePINyouEnteredWhileRequestingCSJinStep3a –cskpass ThePasswordYouPutWhileCreatingCSKinStep3b fullpathofthedownloadedCSJfile.csj

Note that you have “Three” specific information to provide above

-          ThePINyouEnteredWhileRequestingCSJinStep3a

-          ThePasswordYouUsedWhileCreatingCSKinStep3b

-         fullpathofthedownloadedCSJfile.csj i.e. the full path of the file with the .csj appended e.g. c:/users…/client-RDK-1234****.csj

Select “Enter” on the keyboard. You should get a notification saying “Successfully registered with server” on the command line. An email is also sent to you from webserver@ws-smtp.rim.net with the subject “Successful Registration Request for Client 1234****”

STEP 3d: Create the .P12 Certificate that will be used for your app signing

-          Enter the following in your command line

Blackberry-keytool –genkeypair –keystore DesiredCertificateName.p12 –storepass Password –dname “cn=YourCompanyName” –alias author

Note that you have “Three” specific information to provide

-          DesiredCertificateName.p12 i.e. any name you desire plus the .p12 appended

-          Password: Though it could be a new one, I highly recommend you use same password from Steps 3a and 3b above to avoid confusion

-          YourCompanyName i.e. the name you desire. Please note that this name CANNOT contain commas. Spaces may be used. Lastly, ensure you use the ‘cn’ and the quotes (“”) as in the example

Once done, the certificate (an envelope-looking symbol with a key) is created in the path where you are calling the commands. Go into the path and copy it into your desired folder.

STEP 4: Packaging the bar file. The BB 10 apps use the .bar file format hence, you have to package the helloworld.swf (a simple helloworld file published as swf from the Flash IDE) file along with associated files or assets (audio, folders, icon etc). In our case, we don’t use any associated assets.

First, here are the required files for the process:

-          Application descriptor XML file. This file usually contains the name of the app then an hyphen and app. In my case, my main file is titled helloworld.swf thus, my application descriptor file is entitled helloworld-app.xml.

-          An icon file. The icon that’ll be specific to your app. It should be 114 X 114 pixels and saved as .png format.

-          A splash file in jpg format. I usually prefer it to be sized as the device target. For the Dev Alpha device spec of 1280 X 768 thus I use same for my splash size. Note that this splash screen is an optional feature.

-          Lastly, a bar-descriptor XML file that contains information about the icon and splash screen mentioned above. For those of us familiar with Playbook development, it is the same as the blackberry-tablet.xml file.

As a caveat, I like to have all my files in one directory hence, copy all your files into a folder. In this case, I simply created a folder in the C:\ directory, named it helloworld and dumped all my files into it. Ensure you also have the p12 certificate created in Step 3d above copied into the folder too as you’ll be referencing it later.

Step 4a: Create the bar-descriptor.xml file as follows. I recommend using a notepad. Copy the following changing say the publisher value to reflect yours and save as bar-descriptor.xml in your folder where you have other files.

<qnx>
<initialWindow>
<systemChrome>none</systemChrome>
<transparent>false</transparent>
</initialWindow>
<publisher>Genii Games</publisher>
<category>core.games</category>
<icon>
<image>helloworld-icon.png</image>
</icon>
<splashscreen>
<image>helloworld-splash.jpg</image>
</ splashscreen >
</qnx>

Step 4b: Create the app-descriptor xml file. Remember it is named as follows: [appname]-app.xml. In this case, we name it helloworld-app.xml

For Adobe Flash 5.5 users, it is auto-generated for  you when you publish to Android. For this exercise, you can simply modify the following below and save as your app’s.

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”no” ?>
<application xmlns=”http://ns.adobe.com/air/application/2.6″&gt;
<id>helloworld</id>
<versionNumber>1.0</versionNumber>
<filename>helloworld</filename>
<description/>
<name>helloworld</name>
<copyright/>
<initialWindow>
<content>helloworld.swf</content>
<systemChrome>standard</systemChrome>
<transparent>false</transparent>
<visible>true</visible>
<fullScreen>true</fullScreen>
<aspectRatio>landscape</aspectRatio>
<renderMode>auto</renderMode>
<autoOrients>false</autoOrients>
</initialWindow>
<icon/>
<customUpdateUI>false</customUpdateUI>
<allowBrowserInvocation>false</allowBrowserInvocation>
<android>
<manifestAdditions>
<![CDATA[<manifest>
</manifest>]]>
</manifestAdditions>
</android>
</application>

Step 4c: Create the BAR file

-          On the command line, type the path of your folder using the line cd followed by the path. In my case it is cd C:\helloworld

-          Type the following into the command line and select the Enter key on your keyboard

blackberry-airpackager -package helloworld.bar helloworld-app.xml bar-descriptor.xml helloworld.swf helloworld-icon.png helloworld-splash.png

Remember to leave spaces between helloworld.bar, helloworld-app.xml, helloworld.swf, helloworld-icon.png and helloworld-splash.png

Also, the texts in red indicate the names of the desired bar file, the xml files created in Steps 4a and 4b above, the desired icon (114*114 pixels) and splash

If successful, you should see the file in the directory C:\helloworld.

STEP 5: Signing the app. This allows for you to distribute the app to the BlackBerry app world. It’s a two step process as explained below

With steps 3 completed, you should now have your .P12 certificate (a file that looks like an envelope with a key underneath).

Ensure it is copied into your directory in this case, the c:\helloworld folder

Also, remember that internet connection is required for this signing as it sends the request to RIM

STEP 5a: Signing with RIM.

Type out the following lines in your command line

blackberry-signer -verbose -cskpass CSKPassword  -keystore CertificateName.p12 –storepass StorePassword helloworld.bar RDK

What follows is couple of lines that should end with a bar signed message if successful.

STEP 5b: Signing the package with your (author) side

Enter the following in your command line

blackberry-signer -keystore CertificateName.p12 -storepass StorePassword RimSignedBarFile.bar author

STEP 6: Deploying to the Device

-          First, go to the settings menu of your device, select “Security”. Then, “Developer Mode” and turn it on. You’ll be asked to enter a password or create one if none is existent.

Finally, enter the following in your command line

blackberry-deploy -installApp -device DEVICE_IP -password DEVICE_PASSWORD C:\helloworld.bar

Note the following

  •  DEVICE_IP i.e. the IP of the device which can be found in the settings menu
  • DEVICE_PASSWORD i.e. the password for the device

STEP 7: Submit your app to the app world by following the link https://developer.blackberry.com/appworld

Conclusion

Finally made it through to the end :-). Do please let me know if you have any issues. Until my next piece, happy development.

Adebayo Adegbembo

t| @technobayo
e| bayo@geniigames.com
w| http://www.geniigames.com