I’m creating a tutorial series on creating iOS apps from the ground up. Take a look at the first video, it will get you started programming iPhone apps even with no experience. I’ll be exploring this more on BuildingMobileApps.com, if you want to follow along there.
I’ve been doing more training, teaching, and documentation projects recently, and it’s been a lot of fun. In July, I led a three week on-site summer technical leadership program for new college hires. The training focused on Amazon Web Services, building APIs as microservices (and deploying them), relational and NoSQL databases, and test-driven development with Java.
I’ve given the AWS, building APIs, and databases training as a two-day class now to motivated students, and it’s been really fun – I’m constantly learning new things as I go when it comes to teaching the material. Not necessarily on the subject material, but on the questions the students ask, and more importantly, where they get stuck.
This wouldn’t be as effective if I wasn’t taking on these types of projects already, so I am continuing to do software development as well. Otherwise, I could easily end up with stagnated skills, teaching say, Objective-C, until the demand for that type of thing goes away. Instead, by taking on projects using Swift for iOS development, it backs up my ability to teach a class that uses Swift.
Recently, Cordova added the ability to require Android libraries as Gradle dependencies. This helps with projects that can share dependencies, as well as saving a manual installation step. Because of some user-reported conflicts with other Cordova plugins, I updated the Twilio PhoneGap plugin to support Gradle installation of the Android support v4 library.
Check out the latest here – I also need to do another compatibility round of testing with the latest Cordova and Twilio libraries.
At the April Austin Microsoft Developer Meetup, I gave a talk about using Microsoft’s Visual Studio Code to build web applications and API’s with Node.js. I also showed everyone how to quickly and easily deploy those Node.js web applications to Microsoft Azure’s App Services.
We used both Express and Hapi to build web applications – one was a simple Hello World web application, and one was a simple API that returned meetups as JSON.
This was a fun presentation to give – there was a lot of discussion with the whole group, as we talked about some interesting areas of Node.js, Azure, and Visual Studio Code – for instance, we found out that VS Code has support for conditional breakpoints for Node.js (right click on the breakpoint, select edit, and then set your condition), and we spent some time digging through the Azure Portal for logging.
My “Are We There Yet?” app for kids on road trips, MapRhino, was just updated to version 1.0.3.
This latest version provides a fully responsive user interface across all sizes of iPhone and iPad, so that you can see more on your screen on the iPhone 6 Plus than on the iPhone 4, 5 or SE. If you’ve bought your kids that 12.9″ iPad Pro they’ve been asking for, they’ll see a lot bigger map on that device as well! Ok, most people certainly won’t do that, but now it has nice support if they do.
In addition, the maps have been upgraded for better offline access, and the app now requires iOS 9 to support all of the latest features.
Try it out and let me know what you think!
For those of you using the Twilio PhoneGap/Cordova Plugin https://github.com/jefflinwood/twilio_client_phonegap, I have just updated with Marco Padillo‘s pull request to fix a deprecated Cordova iOS method that was preventing compiling with the 4.1.0 version of the Cordova iOS plugin.
I’ve tested out the plugin with the latest Twilio Client libraries, and everything is great except on the Android side with Marshmallow – the latest Twilio Android Client SDK supports the new runtime permissions, so I’ll need to integrate that and test with my Nexus 7 for Marshmallow support. In the meantime, just target API 22 on the Android side.
I’m working on a new technical programming book – Building Mapping Apps for iOS With Swift. Many of my UT app teams are working on map and location based apps, and all of them are using Swift as the language for their iOS apps. The first chapter is written, which is always the hardest part of writing a book!
I’m publishing the book on Leanpub, so that you can get access to the book as it is written, and provide feedback as I go along. In the past, when I’d written technical books or articles, it’s a lot of work done behind the scenes, and then a 300 page book ends up on the shelves of the local Barnes and Noble. If we’re lucky, it will sell well enough that the publisher will invest into a second or third edition (like Beginning Hibernate/Pro Hibernate). With the Leanpub model, readers can get started immediately with the book.
Check out the preview book page here:
And sign up on the mailing list to get notified when the book is published. If you have any feedback on topics you would like to see covered, please contact me through this site, or at jlinwood at gmail.com.
I just recently gave a one-week training class on Amazon Web Services for corporate developers that were new to the cloud. We covered EC2, S3, Elastic Beanstalk, Glacier, ElasticSearch, Elastic Load Balancer, costing, scaling, and quite a few other topics. Most of the training was language-neutral, but we used Java for the programming exercises.
In addition to the AWS class, we also did a half-day exercise on Test-Driven Development with Java (using JUnit 4), which I could have expanded out to a full day pretty easily.
If you’re interested in either of these classes, or training classes on iOS or Android, feel free to contact me through this web site. I’m working on building out some supporting training materials and additional exercises for both of these classes.
Earlier this month, my wife Cheri and I finished running a marathon (or longer) distance in each of the fifty states of the US by finishing the Maui Oceanfront Marathon in Hawaii. It was a goal I’d worked on since my first marathon, in Maine, in October 2008.
I gave a talk on running in all 50 states today at Link Coworking as part of the Link at Lunch series, and I wanted to share the slides.
As a mobile app developer, I use many third-party libraries in my Android and iOS applications. Most of them are open source, but a few are closed source, commercial libraries (such as Flurry, a mobile app analytics SDK).
One of the problems that I’m running into, especially as I have plenty of apps that are now past the “active development” stage, is that these third party libraries don’t necessarily function well on the latest versions of the mobile operating systems. This usually doesn’t affect the shipped version of the apps – iOS in particular does a great job of simulating older operating systems, so that an app that was compiled for iOS 4 will run fine on an iOS 9 device, although the screen size won’t be the best for the newer iPhones. Android lets you specify which SDK version you are targeting, as well as the minimum SDK version you support – you can probably safely get away with supporting Android 4.0 and above for new projects, ignoring the older Android phones running on Android 2.3 (Gingerbread).
The catch comes when it’s time to update these apps – new content, a new visual style, even just an upgrade to support the latest screen sizes. Now a lot of the libraries that may have been ok in 2012 have started to show their age, in particular with iOS’s Adaptive Layout for responsive designs on iOS. Various quirks surface that need to be worked around, and a simple project to update something can take more time than is really needed.
What if you weren’t stressed about upgrading your apps? What if you’d just made updating the app’s libraries part of an ongoing process – some upgrades are necessary (security fixes, new operating system updates), and others weren’t? It’s not like it’s terribly hard to do with either CocoaPods on iOS or Gradle on Android – but out of sight, out of mind, until you get that hard deadline.
I’m building a service that takes your CocoaPods Podfiles, and your Android build.gradle files, and monitors all of this for you. I’m starting with CocoaPods first, as I think the need is greater there due to the way iOS breaks compatibility at the view layer, and then doing Gradle later. You’ll simply get an email any time a CocoaPod or Android library gets updated at the central repository, and you can decide when to upgrade. You can monitor the status of all of your projects on a dashboard to get a quick view of any technical debt that may have started to accumulate.
If you’re using continuous integration, you’ll be able to fire off a quick API call to the service to update your Podfile.lock or build.gradle to keep your project up to date.
Are you a mobile app developer who’s currently stuck in maintenance mode? Would you like to be on top of things, instead of constantly working from behind? Email me at firstname.lastname@example.org so that I can put you into the beta version of the application. I’m just as excited about this as you are!