0
0
was successfully added to your cart.

Cart

Category

development

Aug 25
0

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

Sep 12
0

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.

Aug 11
0

Quick and Easy iPhone Gradients

By | development, iPad, iPhone, Mobile Development

The market for iPhone and iPad apps is competitive and sometimes a bit of extra eye-candy goes a long way. For a couple of projects I have had to give various items a gradient shaded background. There are two ways to do this. Core Graphics or Core Animation. Gradients in Core Graphics give you more customization and more control, but are more complex to implement, while gradients in Core Animation are simple, but may not be able to do everything you need. Here we are going to look are the fast Core Animation approach.

Make sure you #import <QuartzCore/QuartzCore.h>

To make a simple rectangular gradient all we need is to add a CAGradientLayer:

CAGradientLayer * gradientLayer = [CAGradientLayer layer];
gradientLayer.frame = CGRectMake(0, 0, 80, 60);
gradientLayer.colors = [NSArray arrayWithObjects:(id)[[UIColor redColor] CGColor],(id)[[UIColor greenColor] CGColor], nil];
[self.window.layer addSublayer:gradientLayer];

This produces a rectangle that can be used in any view:

We can give the layer rounded corners by adding:

gradientLayer.cornerRadius = 10;

For more complex shapes we can set a mask for the gradient layer using a CAShapeLayer:
//Make shape – Triangle
CGMutablePathRef path = CGPathCreateMutable();
CGPathMoveToPoint(path, NULL,40.0f, 0.0f);
CGPathAddLineToPoint (path, NULL,80.0f, 60.0f);
CGPathAddLineToPoint (path, NULL,0.0f, 60.0f);
CGPathCloseSubpath(path);

//Shape layer
CAShapeLayer * mask = [CAShapeLayer layer];
mask.path = path;
[gradientLayer setMask:mask];

//release path
CGPathRelease(path);

UIButton with a gradient:

 

The graph I made for a project using Core Animation layers:

Jun 29
0

Objective-C: Blurry UIView

By | development, iPad, iPhone, Mobile Development | No Comments

If you’ve been coding Objective-C interfaces for a while you will know that you set the position of a view using it’s frame property. This property is a CGRect which is made up of four float values.  newView.frame = CGRectMake(0.0, 0.0, 100.0, 100.0);

At first these floats were quite an annoyance because when debugging using NSLog() to check if frames were set correctly you have to use NSLog(@"%f",newView.frame.origin.x); and this is printed as a decimal number i.e. 0.00000

After getting used to this and starting a project that required 3 columns down the screen I thought that I could finally use the floats to their full effect. So I divided the space neatly by three and drew UILabels. UILabel *firstLabel = [[UILabel alloc] initWithFrame:CGRectMake(0.0, 0.0, 1024/3, 768.0)];

Unfortunately this caused my UILabels to become fuzzy or blurry. After an extensive google search I found out that you should NOT be setting your frames using float values. Although CGRects take float values, when a UIView gets drawn and it has a decimal value in the frame it will blur that value to the nearest integer. This makes sense when you remember that the value you are giving is meant to represent a pixel value and a view cannot end halfway through a pixel.

So you should ensure that your frame does not contain any decimal values. An easy way to do this is to use the roundf() function. If placed around all 4 values in your frame you will always have an integer value, however this is a lot of extra code and you only have to do it where there is a possibility of having a decimal value. So my above label example became
UILabel *firstLabel = [[UILabel alloc] initWithFrame:CGRectMake(0.0, 0.0, roundf(1024/3), 768.0)];

Using a view’s center property it is possible to get a point with a .5 value (any view with a width or height that is odd will give you a .5 value). Using a view’s center to position another view should therefore be done using roundf(). For example say you have a white view and you want to cover it from the middle to the bottom right corner with red:

UIView *bigView = [[UIView alloc] initWithFrame:CGRectMake(30.0, 30.0, 67.0, 71.0)];
bigView.backgroundColor = [UIColor whiteColor];
[self addSubview:bigView];

UIView *smallView = [[UIView alloc] initWithFrame:CGRectMake(
                                roundf(bigView.center.x),
                                roundf(bigView.center.y),
                                roundf(bigView.frame.size.width/2),
                                roundf(bigView.frame.size.height/2)
                                                                                                )];
smallView.backgroundColor = [UIColor redColor];
[self addSubview:smallView];

[bigView release];
[smallView release];
Jun 24
0

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 🙂

Mar 14
0

Xcode 4.0 is here!

By | development | No Comments

For all of you that have been waiting for Xcode 4.0, it’s finally here! Xcode 4.0 is quite a major update from Xcode 3. It’s almost completely different. I’ve recently installed it and have been using it for a little while, but I’m still yet to decide whether I like it or not. There are a lot of nice additions like the assistant window, interface builder built in, fix-it and live issues. Apple has seemed to have jammed everything into a single window interface. The only downside I’ve found so far is that I don’t know where a lot of things are since they’ve moved things around quite a bit. Hopefully I’ll eventually understand how everything fits together and start to like this new Xcode. I really want to. Luckily though, for those who don’t like it, Apple still allows you to download Xcode 3.

For all you registered Apple developers, you can download Xcode 4 for free. For those who arn’t, you can get it off the Mac App store for $4.99.

Feb 17
0

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 😉

Feb 07
0

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 😛

Jan 26
0

Windows style Home and End buttons on Mac

By | development, Hacks, Uncategorized | One Comment

The Home and End buttons behave differently in Mac and Windows. In Windows the Home button takes you to the start of a line and the End button takes you to the end of a line. Pressing these while holding in Shift allows you to quickly select a line. In Mac the Home and End buttons take you to the start and end of the document as opposed to the line. This can also be used in conjunction with the shift button to select a large portion of a document.

The difference in the behavior of these buttons can be very frustrating especially for developers switching from Windows to Mac. Fortunately Xcode provides an easy way to change the behavior of key presses which can be used to make End and Home behave like your in windows.

Open Xcode’s Preferences.

Select the Key Bindings tab highlighted in red below.

Now select the Text Key Bindings setting also highlighted in red above. The following screen should be shown.

A list of Action’s along with their bound Keys is shown. Scroll down to ‘Move to Beginning of Line’ and double click on the Keys column. Press the Home key to bind that action to the Home key. Underneath this action there is the ‘Move to Beginning of Line Extending Selection’ action, double click the Keys column here as well and bind it to Shift+Home by holding in Shift and then pressing Home. Repeat this process for all the actions underlined in red above. ‘Move to End of Line’ and ‘Move to End of Line Extending Selection’ actions should be bound using the End button instead of Home.

This will change the behavior of End and Home in Xcode but not in any other applications. There are ways to change this behavior more generally. http://lifehacker.com/225873/mac-switchers-tip–remap-the-home-and-end-keys is a guide to doing so, it will however not work in Xcode or custom applications such as firefox.

Oct 21
0

BlackBerry Developer Day – Johannesburg 2010

By | Apps, BlackBerry, development | No Comments

I was fortunate enough to attend the BlackBerry developers day conference in Johannesburg yesterday. The basic idea behind these conference days is to allow RIM to meet up with the local community of BlackBerry developers and to discuss new features and future prospects of the BlackBerry platform.

Despite a recent spate of negativity and pessimism surrounding RIM’s decision for an evolutionary  – rather than a revolutionary – approach to its OS in order to compete with the likes of iOS, Android, etc. it was immediately clear from the day’s agenda and the initial overview that RIM is genuinely excited and 100% behind the BlackBerry 6.0 OS release. Whether or not the excitement is completely justified or not, one very important signal coming from all of this is that RIM is putting in a substantial effort to improve conditions for its developers, not only from a new features and APIs point of view but also technical documentation and online code samples; this can only be a good thing going forward.

As part of the agenda, BlackBerry covered a wide array of new improvements coming from their latest OS releases. Of the topics discussed, I found the following most interesting:

  • RIM is making a big push to encourage developers to forget about targetting pre 5.0 releases with new development and to rather focus on 5 and 6 releases onwards. Their main argument for this comes from OS statistics showing that the OS 5 release alone is being used by more subscribers (around 38%; see pie chart below) when compared to the previous OS versions individually. RIM also argue that subscribers are upgrading (software and devices) rapidly and the 5.0 slice will continue to grow from day to day. I also think that this push by RIM reflects in some way as a self-acknowledgement of the unfriendly environment that pre OS 5.0 releases have provided its developers. I found this quite interesting being in South Africa and I’m not sure if I entirely agree with RIM here. Yes, the 5 OS update is a significant improvement, however, I’m not sure if it is in the best interests of developers to neglect pre 5 OS releases,  considering the following: 1) the combined subscriber count of the 4.5 – 4.6.1 releases still outnumbers that of the 5.0 release; 2) OS updates reaching the end user are carrier dependent; and 3) the BlackBerry Curve 8520 – which has been mega in South Africa – still runs a pre 5.0 BlackBerry OS.

  • BlackBerry are set to release APIs for use with their BlackBerry Messenger Service (BBM). The APIs will allow applications to build functionality on top of the already extremely popular IM service. Some of the functionality includes embedding chat within an application and sharing content amongst users. Essentially, this will allow developers to integrate the social platform provided by BBM into their applications.
  • New APIs and components available to BlackBerry OS 6.0. Without going into too much detail here, several new APIs, UI components, and the ability to tightly integrate an application with the OS (something referred to as a “Super App”) were explained at the conference.
  • Fragmentation. The issue of fragmentation amongst the BlackBerry OS versions and devices was flagged as a concern for the future prospects of the platform. I’m not really certain how BlackBerry are going to get around this, particularly as their devices cover such a wide range of the market audience. It also doesn’t help that their new tablet – the BlackBerry PlayBook –  will be running an entirely different operating system in QNX.

All in all, the conference day was a success and a first step towards growing a stronger local developer community. RIM is putting a tremendous amount of faith in their OS 6.0 release to help them grow their smartphone market share against some stiff competition. Let’s wait and see…. time will tell 🙂