Tag

development Archives - Cobi Interactive

Google Developer Summit 2015

By | Android, Apps, Cape Town, Cobi News, development, Events, Mobile Development, Uncategorized | No Comments

Cobi attended the Google Developer Summit on Tuesday, 25th August 2015. The event was organised by the Google Developers Group for Sub-Saharan Africa and was divided into two tracks: Android and Web Development/Cloud. The team attended the Android track to gain more knowledge on this rapidly changing platform.

The first of the morning’s talks was called “Building for the next billion users” and was presented by Abodunrinwa Toki, a software engineer at Google focusing on Android UI Toolkit and Google Docs. The talk discussed the challenges that developers face when developing Android apps for users in emerging markets. These challenges include:

  1. Smart data usage
  2. Minimising APK size
  3. Smooth and responsive user interface
  4. Minimising memory usage
  5. Minimising battery usage
  6. Optimising app architecture

The following talk gave us deep insights into Material Design and was presented by Takuo Suzuki, Developer Relations Japan Lead at Google. Takuo explained that Material Design is a set of design principles that unifies apps across all platforms whether it be mobile, web etc. The talk explained the four tenets of Material Design: tangible surfaces, print like design, meaningful motion and adaptive design, followed by a discussion of the design support library.

The afternoon was devoted to a code lab that was coordinated by Alex Koller. This gave developers an opportunity to experiment with the new material design features available in the design support library. We implemented some of the most common features such as Toolbar, RecyclerView, CoordinatorLayout, SnackBars and the FloatingActionButton.

Google Drive

Mobile Developer’s Guide To The Galaxy

By | development, Mobile Development, Uncategorized | No Comments

Although I’m mainly on the Java dev side at Cobi, I’m always interested in reading about various cross-platform solutions.

Yesterday I stumbled across a very nicely built, but simple, payments app – bill payments in South Africa – called POCiT. What I found interesting about this app, is that it is written using the J2ME Polish platform (Enough Software), and it has come a long way since I last checked it out. And I really liked the speed of the app compared to PhoneGap apps which can be really slow. I’ll try to write more on Polish at a later date.

But the reason for this post is that I found a great introduction to development on mobile platforms on the site. They call it the Mobile Developer’s Guide To The Galaxy and I recommend anyone interested in the field to download and read it. It gives a brief overview of all mobile platforms & how to develop for them; introduces many of the cross-platform development kits & also gives a rundown on mobile web apps. All in all, it is what it says it is – the guide to our galaxy.

Deploying a BlackBerry app for OTA installation

By | BlackBerry, development | No Comments

When testing a build of a BlackBerry app, one method to deploy the app on a BlackBerry OTA is to host all of the application COD files and a main JAD file with the relevant details of each COD file in it. Once hosted, one can point the BlackBerry device to the JAD file being hosted and the application COD files will be installed on the device.

While this isn’t such a problem with single projects in isolation, anyone who has had to do this manually where multiple projects (such as library projects) are involved in the deployment of a single app, will known that the process of assembling the COD details into a single JAD file is rather menial and in general quite insufferable. Fortunately, the BlackBerry JDE comes with a tool called updatejad.exe and works as follows:

Let’s use a main project name of Peanut and peanut relies on the library projects Raisin and Salt. To assemble the Peanut.jad file with the COD details of all the projects, one can use the following command:

updatejad.exe Peanut.jad Raisin.jad Salt.jad

I find it easiest just to copy the necessary JAD and COD files to a single directory when running this command. There you go… you now have a deployable JAD file to host along with all of the application COD file 🙂

BlackBerry: Catering for multiple OS versions with a single code base.

By | BlackBerry, development | One Comment

One of the challenges involved with BlackBerry development is the need to produce code that is able to cater for a variety of devices, running different OS versions and with differing screen sizes. In an ideal scenario, one would want a single code base that can be built against different BlackBerry OS versions, if needs be. A problem begins to emerge when one needs to access an API which doesn’t exist in some of the OS versions you are targetting… clearly, if it doesn’t exist to your compiler, it won’t build. Whilst BlackBerry has support for Java reflection – the mechanism to dynamically obtain a class at runtime by the use of the class name – the support is basically limited to only class loading…. one cannot actually call actions/methods on the loaded class dynamically.

I’ve just recently come across this issue where I needed to access a class introduced in 4.7, but my code base was building against 4.5. My specific problem was that I needed to restrict the orientation of my application, however, the class allowing me to do so was only introduced in 4.7. Instead of having to create two separate projects to build against different versions, I came across a solution here which allowed me to target different versions from the same code base. Essentially the solution relies on preprocessor compiler directives to dictate which pieces of code ultimately get compiled.

As a quick example of how something like this will look in code, I’ve included the piece of code that enabled me to restrict the orientation of my application (using a class from 4.7) within the same code base that is also built against 4.5.

private void setOrientations()
{
//#ifndef JDE_4_7_0
/*
//#endif
int directions = Display.DIRECTION_NORTH;
Ui.getUiEngineInstance().setAcceptableDirections(directions);
//#ifndef JDE_4_7_0
*/
//#endif
}

The directive JDE_4_7_0 will need to be defined in the project application descriptor when building against 4.7 – for full configuration instructions, see the previous link posted. What you will notice from the above code is that when the directive is not defined (in my case when building against 4.5), the piece of code is commented out and as a result the 4.5 compiler will never complain about the code that was only introduced in 4.7.

Obviously, this type of setup can become very messy if used excessively; however, I think it is a great solution for simple pieces of code when one needs to access APIs in different OS versions from the same code base 😉

When you wish you had a strongly typed compiler!

By | development, iPhone, Rant | No Comments

The other day a work colleague of mine ran into some troubles with an unrecognized selector exception crashing his iPhone application…the exception looked something like this:

NSInvalidArgumentException’, reason: ‘-[__NSArrayI addObject:]: unrecognized selector sent to instance …..’

After much frustration, and a fair bit of time spent with a bunch of us trying to hunt down the problem, it turned out to be a problem that could have been noticed immediately had the compiler been strongly (stronger) typed. Yes, ultimately the problem arose due to programmer error, however, this particular instance is just one example of why I prefer strongly typed languages (such as Java).

The error came about as a result of attempting to add an object to an NSMutableArray type that was actually pointing to an NSArray object. This type of scenario is shown in some demo code below:


NSString *test = @"test";
NSMutableArray *mutableArray = [[NSMutableArray alloc] init];
[mutableArray addObject:test];
NSArray *immutableArray = [[NSArray alloc] init];
mutableArray = immutableArray;
[mutableArray addObject:test]; // Exception: unrecognized selector

From the above code, it is easy to see that a subclass type is being assigned to a superclass type. In Java, for instance, this would immediately have been flagged as an error (conversion error between types), and the problem resolved fairly quickly. To be fair to Objective-C, a warning is given when attempting to perform an incompatible assignment, however, this simply just does not seem to be enough sometimes and the result can be a real pain for developers. Fortunately, this time around, it was not myself who bore most of this pain 😛

BlackBerry’s Alliance Program takes my breath away – and not in a good way

By | BlackBerry, Mobile Development, Rant | No Comments

A big attraction for BlackBerry users is the BIS (data) network and the way BlackBerry contracts are structured so that access to the network is charged at a flat and fairly low rate. As a result users feel they are getting unlimited mobile internet access cheaply.

Given Apple’s hold on the mobile app market and BlackBerry’s apparent desperation  to attract developers you would think that providing developers with easy access to the BIS network in their apps would be a given for BlackBerry. Unfortunately and to my amazement, this is not the case.

To gain approved (there are unapproved ways) access to the BIS network, you need to be a member of the BlackBerry Alliance Program in the associate tier. Sounds easy enough? Not quite… In addition to paying $2000 a year, to be an associate tier member you need to earn 45 member points; which can be earned in the following ways, many of which border on ridiculous:

Activity Point Assignment
Revenue Impacting
Influenced Revenues 0-10 per quarter
Desired Behaviour
Customer References (limit to 2 per year) 5 per submission
Valid Case Study (limit to 1 per year per partner, only if approved by RIM) 10
Completed Competency (through Certifications, see Certification Requirements) 10
Events
Sponsorship of RIM Organized Event (maximum points awawrded each year is 10) 10 per sponsorship
Company representation at the BlackBerry Developer Conference 5
Company representation at WES 5
Company representation at Alliance Summit (either North American or European) 5
Completion of Alliance Member Survey 3
Promoting BlackBerry Alliance Membership on your organization’s website 5
Requirements Completed
Submit quarterly activations or PIN numbers 2 per quarter
Up-to-date company profile and contacts 2
Up-to-date solution submission for RIM distribution 2
Sales tools submitted for RIM distribution 2

Giving points out for conference attendance and sponsorship smacks of desperation to me; and from a development houses point of view the rest look about as attractive to earn as writing Symbian apps. Companies don’t want users of their BlackBerry apps to be charged for data; and so when they have the choice of putting an iPhone app out or a BlackBerry app; this plays a major factor in helping them make that decision.

After numerous grumbles such as mine above, RIM has claimed that the BIS access will move down to the free, ‘0 member points required’ tier of the program. I asked them in January when this change would happen, to which they said February. Well, tomorrow is April and I still haven’t heard anything…