Tag Archive for iOS

A Swift Softening

enter image description here Listeners to last week’s Coder Radio know that during the live feed WWDC coverage, I was less than enthused with the announcement of Swift, Apple’s new programming language for iOS and OS X. My initial reaction was based on the somewhat unclear way they announced Swift; it was not very clear what they wanted us developers to use Swift for and that led me to the wrong conclusion that Swift is designed to be a near to medium term 100% replacement for Objective-C – this simply is not the case. So far, I’ve read through the Swift book on iBooks and the documentation publicly available twice and found something very surprising – Swift reminds of QML in QT.

This might sound a bit odd, given that in a lot of significant ways Swift and QML are very different languages, but they actually share a kindred spirit and will likely take the same place in my tool-chain – layouts. Yes, both Swift and QML are technically capable of so much more than layouts but really they are both well suited for that task in particular. Why do you think the WWDC demo was so UI / visuals heavy?

So the bottom line is no I don’t hate Swift and no I don’t think it will be the end of Apple development as we know it. And yes, I will be using it but, at least for the next year or so, in the same capacity as QML and its relationship with Objective-C will be same as QML’s with C++ in my QT code-bases.

Questions? Comments? Find me on Twitter.

Going Mobile: Byword

This is the first entry into Going Mobile my series of reviews on mobile productivity software – I am defining productivity software as any software I use to get work done. For this first entry we have Byword for iPad, a great markdown editor for iPad (and actually iPhone too). It’s fitting that the first pick be a markdown editor, since the majority of this website has been written in markdown for some time; in fact, this post post has been drafted in the app on my iPad Mini.

Byword doesn’t strain itself to be the best looking iOS app on the market; in fact, it focuses more on function than form, however, it is still a pretty good looking app and leans very heavily toward the iOS 7 design paradigm.

What puts Byword ahead of the pack of mobile markdown editors is its integrated posting to Word Press and a number of other blogging platforms. This might seems like an unnecessary convenience but the fact is that effective blogging from a mobile device requires that the process be as frictionless as possible. A close second for my favorite feature in the app, is dark mode. Given iOS 7’s relative hostility toward nighttime use around a sleeping partner or spouse, it is refreshing to see third party developers taking the time to add dark modes and other quality of life features.

The app costs $4.99 currently and to unlock some of the advanced publishing capabilities, you have to purchase a $4.99 “premium” in app purchase. This is my only issue with the app – the app feels pretty incomplete without the in app purchase. That’s not to suggest that the app isn’t well worth it’s true cost of $10, but rather that this pricing scheme feels a little deceptive and in my mind brings down the (for lack of a better term) “class” of what is otherwise a very high-end experience. I’d gladly pay $10 for the app outright but understand that I’m in a fast shrinking minority; the reality is that thine pricing scheme probably was decided upon due to the unfortunate economics of the app economy.

If you’re in the market for a mobile markdown editor and are an iOS user, then I strongly recommend that you check Byword out. If you have any comments or app suggestions, please share them with me on Twitter.

Time to Go Mobile

If you read my 2014 Predictions, then you know that I don’t believe that we are going to see a lot of huge leaps in mobile hardware or OS technology in the next year. Software from third party developers however will be a different story. Indeed, it is my belief that 2014 is the year that large numbers of normal users are going to begin using their mobile devices as the power personal computers they really are – in many ways, a mobile device is a far more personal computer than an actual PC at this point.

I’m going to be one of these brave few and will therefore start featuring and reviewing applications that I use on a variety of devices. However, I am not going to artificially promise to review an app per week. Nor am I going to worry about making sure all platforms get the same amount of coverage. My goal is to honestly review and recommend apps that I use regularly on whatever platform.

Since these are apps that I actually use, there will be no negative reviews – in fact, there’ll be no scoring at all, as I find the star or X out ten scoring systems to be arbitrary at best. Think of these apps as my picks and treat them that way. If you like what I like and you find something that you start to use often from these posts, then please let me know on Twitter or Google+.

MDNetworking: My Little Networking Lib

Disclaimer: This is in no way a 1.0 codebase and I strongly recommend against you using this in production.

Summary: MDNetworking is a small Apache 2.0 licensed Cocoa / Cocoa Touch library. It is intended to be suitable for use on iOS7+ and Mac OS X 10.8+ but it may in fact be possible to get it working on older version of iOS and OS X. My intention in creating this library is not to make yet another heavy Cocoa networking framework that is going to solve the meaning of life and the world’s problems. I merely want to present a relatively simple and easy to use facade of NSURLConnection and the like.

Contributing: I’m open and welcome contributions from the community, however, any contributions that don’t adhere to the present code-style will be rejected.

Good Night CJ for iOS

Everything has its time and then it moves on. That's the story with Code Journal for iOS. It was a fun project but never really hit its stride when compared to the Mac version.

To be fair, I had fun developing the app and, since it shared a lot of code from the Mac app, didn't have to invest a whole lot of additional time in its development; still, one could easily argue that the lack of a specific investment is one of the reasons that the app failed to gain a large user base.

Was Code Journal for iOS a failure? Well, that depends on how you think about it: yes, I didn't make a significant profit on it but I did get some use out of it personally.

Some of you have written me asking why I am pulling the app now. In truth, it is two-fold. First, the update to iOS 7 would require working with a designer and paying that designer for assets etc. Second, I stopped using the app, especially compared to the Mac app which I use everyday.

Pallet Town: Intro to AFHTTPClient Part 1

Pallet TownWelcome to Pallet Town! Pallet town is going to be an ongoing bi-weekly look at various development technologies and techniques from the perspective of someone new to that technology. For those who might know or (God forbid) are too young to get the reference, Pallet Town is the first town in the original Pokemon games for the Nintendo Gameboy.

This week we are going to take a look at getting some simple networking done with the new hotness in iOS networking frameworks: AFNetworking. To be specific we are going to focus on one of its more important classes: AFHTTPClient Now there are is a little bit of a prerequisite here, we are going to go ahead and assume that you have already added AFNetworking to your iOS project and we are also going to assume that we are going to use ARC.

For starters, let’s take a look at how we instantiate the AFHTTPClient:

Now that we have our client, let’s say we want to make a simple RESTFul GET call; this sample builds a bit on our Pokemon themed ASP.Net MVC web app from the last installment of Pallet Town. Ideally, this call would just get all the Pokemon available on the API; this of course assumes you followed the normal MVC patterns in your routing on the API. Here’s the code:

- (void)getAllPokemon
{ 
	AFHTTPClient* client = [[AFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:@"SOME_URL_STRING"]];
	[client getPath:@"api/pokemon/" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
			NSString *responseStr = [[NSString alloc] initWithData:responseObject encoding:NSUTF8StringEncoding];
			NSLog(@"Request Successful, response '%@'", responseStr);
		} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
				NSLog(@"[HTTPClient Error]: %@", error.localizedDescription);
	}];
}

That was fun but let’s make things a little more complicated. Let’s say you want to pull a particular Pokemon via its Id. That’s still a GET request but takes a parameter like so:

- (void)getPokemonById:(NSNumber *)pokemonId
{ 
	NSDictionary* parameters = @{@"Id" : pokemonId}
	AFHTTPClient* client = [[AFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:@"SOME_URL_STRING"]];
	[client getPath:@"api/pokemon/" parameters:parameters success:^(AFHTTPRequestOperation *operation, id responseObject) {
			NSString *responseStr = [[NSString alloc] initWithData:responseObject encoding:NSUTF8StringEncoding];
			NSLog(@"Request Successful, response '%@'", responseStr);
		} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
				NSLog(@"[HTTPClient Error]: %@", error.localizedDescription);
	}];
}

Getting Pokemon from the server is a lot of fun, but you know in the age of Minecraft, I like to  be a little more creative than just working with the set number of Pokemon that Nintendo provides. Tune in for our next installment to see how to POST my very own legendary Pokemon to the server!

UILocalNotification 100

Tomato SoupThere are a lot of cases where you will want to notify your user of some event of reminder without actually setting a formal alarm in their Alarm app. The standard solution most developers seem to take in these situations is to setup something like Urban Airship and fire off a push notification – this costly and shares the user’s data for no reason. Using
iOS’s UILocalNotification, you can pop a push-like notification without worrying about the hassle and potential cost of a push service and without sending any user data over the air. Checkout how easy it is to fire off a simple notification from this simple from my newly released Pomodoro timer Tomato Soup:

- (void)createNotificationForPomo:(TSPomodoro *)pomo
{
	UILocalNotification* notification = [[UILocalNotification alloc] init];
	notification.fireDate = pomo.fireDate;
	notification.alertBody = [NSString stringWithFormat:@"Nice work! Pomodoro: %@ is complete!", pomo.title];
	[[UIApplication sharedApplication] scheduleLocalNotification:notification];
}

// Now let's remove all notifications
- (void)removeNotifications
{
	[[UIApplication sharedApplication] cancelAllLocalNotifications];
}

Notifications like the one created above will still fire if the app is in the background, however, if you don’t want them to fire if the app is active, you will have to deactivate them on willResumeActive.I hope this helps you and that you reconsider how often you send user data over the air and use UILocalNotification as a simple alternative to push when appropriate.

Comments? Questions? Drop me a line on App.net, Google+, or Twitter. Also, pickup Code Journal.

Ubuntu Phone OS: Initial Thoughts

ubuntu-logoLooks like Canonical is serious about making 2013 a big year for the Ubuntu project. As I am sure you are aware, Canonical revealed the Ubuntu Phone OS earlier this week. Unfortunately, like most Linux enthusiast, I have not been able get my dirty little mitts on a device running the new operating system but have been reading everything that Canonical and other sources have written about it. I really would love an Ubuntu-based phone, but have some serious misgivings about the OS: Canonical  doesn’t have carrier relationships, the mobile market is maturing, and you can’t buy an Ubuntu Phone today.

Carriers are incredibly powerful in the mobile space and it is more than a little difficult to release a product without their approval and cooperation. To date, Canonical has no public relationship with any carrier and has never released any sort of device that uses cellular technology*. If you know the history of the iPhone and Apple’s interactions with the major US carriers to get the original iPhone on the market, then you know how difficult dealing with them can be. The telcos are old companies and they run their business in a very old school manner, basing a lot of what they do on relationships.

For the sake of argument, let’s say that Canonical can get a good carrier relationship to the point where the carrier actually promotes and pushes the Ubuntu Phone; make no mistake here — the carriers do push certain phones over others in the stores via ‘sales incentives’. The last time a carrier really stood behind one platform was a huge success for the platform — the platform was Android and the campaign was Verizon’s ‘Droid’ campaign. It’s fair to say that Verizon made Android a household name and can be credited with a lot of the platforms early success, but would they do it again? Would any carrier when they can just work with any of the hundreds of Android manufactures and get a platform they know they can sell? It is widely held that the ‘Droid’ campaign was designed to compete directly with the iPhone, an AT&T exclusive at the time. The market today is different, however, and if the carriers want to push handsets other than the iPhone (perhaps because they can strike a better financial arrangement with a different manufacturer than Apple), they already have the Android powerhouse and the Windows 8 darkhouse. The market is matured and there isn’t just one platform anymore. Worse still for Canonical (and Microsoft but more on that later), a lot of everyday users have spent a lot of money on apps for Android and iOS. I believe that this creates something of a platform lock in scenario that most consumers would be unwilling to move from one platform to another, because they have purchased apps and other content that cannot be moved between platforms.

It’s 2013. You can’t make a huge mobile announcement and not actually have anything consumers can buy, but that’s just what Canonical did. Of course, they will get a lot of Ubuntu fans (myself included) installing the OS on a spare Nexus but, for the mass market, they have just squandered the excitement that the market displays around a new platform launch. Worse still, they have not announced any retail partners. The sad truth is ‘normals’ (non-geeks) buy their devices in carrier retail stores or other outlets. If the Ubuntu Phone does not have a retail presence, then, for a huge market segment, it might as well not exist.

This article has been focussed on showing the issues with an Ubuntu Phone. That does not mean that I am not an Ubuntu fan. In fact, I would it to do well, since more competition in the space is good for developers and the market as a whole. Questions? Comments? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

 

*UPDATE: Thanks to Arthur for pointing out that they did in fact release a netbook running Ubuntu in cooperation with Vodafone. However, they have never released a phone with carrier support.

The Best Feature…

Code Journal LogoI’ve been hard at work mapping out the future of Code Journal  and took some time to go through user e-mails that requested new features; the idea was that I would simply implement the feature that the most users had e-mailed asking for. That feature was a resizable UI.

The problem was that the people, my customers who I of course care a great deal about, were very passionate about this particular feature and the feature seemed simple enough to implement; after all, I’ve implemented resizable UI’s on a number of Mac OS X apps for clients, so why couldn’t I apply the same the techniques to Code Journal? Right? Wrong.

Code Journal started out pretty simple; it was an app that pulled and processed JSON data from the Github API; in fact, the most complicated thing in the private demo (think alpha) version of the app was Github’s OAuth. I was thrilled. The app was nice and simple.

Overtime and as it closer to the all important 1.0, compromises had to be made. There is no need to enumerate them here, but suffice it say that one current feature (Github Enterprise support) is responsible for a disproportionate amount of code and almost all of my support requests. Does that mean I’ll be pulling enterprise support? Absolutely not. The truth is that these request have more to do with customers having non-standard settings on their Github Enterprise deployment or the server that host them, rather than anything to do with Code Journal. Enterprise support is a slam dunk and I personally love being able to user Cde Journal with clients who have Github Enterprise servers; best part is that most of the time all I have to do is fill out the enterprise field in the app with my credentials and we are good to go — no need to bother a sys-admin at all.

In short, the complexity that supporting enterprise customers caused was a good thing. Back to the feature request: resizable interfaces.  I understand why some people might want this feature, but, to be honest, I don’t think it’s a good idea. Even on my 27 inch Cinema Display, I often find myself pressed for screen real estate when tacking some hairy memory management problem or am “in the zone.” Like many of you, I am not willing to compromise by putting my monitoring tools into a separate space and, again like most of you I imagine,  I only have the one screen. The other issue of course is that Code Journal is a Mac app and a lot developers that work on Macs work on 13” laptops.

Still, it’s hard to ignore your paying customers, so I went against my instincts and began coding.  I won’t bore you with the details, but it was doomed from the jump. I spent two weeks coding and agonizing over resizing table views and experimenting with Auto Layout. What resulted wasn’t terrible but had a number of rough edges and, more importantly, was not a feature that I could see myself using and believe would have been a major source of maintenance. The feature is not going to be released. At this point in the product’s life, it is more important to keep complexity out of the equation than to add every suggested feature; this particularly true of features that don’t provide any additional functionality. The best feature is the one you never have to maintain.

Comments? Questions? Share them with me on Google+ or Twitter. This post was made possible by Code Journal and Fingertip Tech, INC. If you are Github user please check out Code Journal and if you are interested in having an Android, iOS, or web app developed please contact me. Also, check out the new free version of Code Journal for iOS.

 

Happy Thanksgiving 2012 Open-Source!

I had a wonderful Thanksgiving this year and, as is common this time of year, friends and family made the normal mentions of things, places, people, or any other sort of noun that they are thankful. Of course, I agree with the most common objects of gratitude: friends, family, etc. However, I got to thinking about work and how thankful I am for the proliferation of open-sourced software. So, I’ve compiled this list of software libraries that I am most thankful for this year.

ASIHTTPRequest: Admittedly, this is a bit older than some of its more popular competitors and there are reasons that one might choose an alternative, but you just can’t be a simple networking interface that includes easy to use caching support. AFNetworking may be the hot new kid on the block, but ASI is still more than adequate for the job. I can’t promise that ASIHTTPRequest will still be my networking framework of choice in 2013 but it has served me well for the last two years and is even a joy to maintain on older apps.

jQuery: Compared to most client-side development, web development is awful. jQuery aims to take pain out of web development and, for the most part, does the job. In the last year, I don’t think I worked on any sites or web apps that did not use at least part of jQuery. I’m sure jQuery will continue to be the ‘go to’ tool for web developers everywhere in 2013.

Rails: Rails has been all over the place this year. I’m very thankful to have had the opportunity to work with it and for it to be introduction to Ruby. For me 2012 was the year of Rails on the backend, however, I doubt that will hold true for 2013. From a consulting perspective, Rails seems to be losing ground to Python-based alternative such as Django and the upstart Node.js. From a more personal perspective, Rails is solving problems I don’t seem to have or rather I have those problems but there are also other issues that it chooses to ignore. Additionally, Rails is going, as is true to its nature, in its own direction (think SASS and Coffeescript) and, in more and more cases, those just aren’t paths I am interested in taking. I have been evaluating alternatives and have come to a decision stay tuned for another post later next week.

There are other projects that I’ve used or use frequently, but these are three that stick out most prominently. Will they all be on next year’s list? Doubtful. Still, I am thankful for them and all the open-source work that makes my job easier and, in some cases, possible. Do you have your own three? Share them with me on Google+ or Twitter. This post was made possible by Code Journal and Fingertip Tech, INC. If you are Github user please check out Code Journal and if you are interested in having an Android, iOS, or web app developed please contact me.