In this post, I propose a pattern for allowing apps to transmit data through unstable network connections. I’ll be taking advantage of the modern architecture present on the iOS Platform, as well as the popular AFNetworking (or AlamoFire). To follow along, you’ll need some knowledge of iOS Native Development, NSOperation API, CoreData, and Networking.
“WHAT THE HECK?! HOW CAN I UNLOCK MY PHONE WITH MY FACE?!”
Those were the words that came out of my mouth in October of 2017, as I pored over the user manual for my new iPhone X. It wasn’t all hyperbole, either — I really wanted to know, and I ended up dedicating quite a bit of time to learning about the science behind Apple’s new facial recognition technology. In the end, the answer to my question boiled down to two words — machine learning.
A mobile app is a great way to bring new ideas to life, add value for your customers, or boost awareness of your business—but only if you can build a quality mobile experience without breaking the bank. And nailing down the cost of an app in advance isn’t exactly easy. App development costs can range from trivial to extreme, depending on a host of factors such as what your app does, how users will interact with it, and how you plan to staff the project.
These days grocery stores are facing many challenges, like high maintenance costs, price competition with online stores, and limited business hours. All of these issues can be solved with unmanned grocery stores.
If you are building a mobile application of any sophistication, you are likely to need some services to support your app. You’ll need a way to distribute your app for testing prior to submitting to the app store(s), as well as analytics, error logging, crash reporting, and possibly user and data management services. Of course, you could write these services yourself and provision servers to host these services, but why do that when you don’t have to?
Your company needs a mobile app and you want to save money (of course). You want the app live last week, and you’d really like to avoid hiring Android and iOS devs on top of your existing web team.
In light of these considerations, going the hybrid route looks like a pretty good option. Hybrid mobile apps promise to be cheaper and faster to develop, and they’re built with tried and true technologies like Javascript, HTML, and CSS. The hybrid sales pitch can be summarized as “one codebase for multiple platforms”. Hybrid platforms include React Native, PhoneGap, Ionic, Titanium, and others.
What’s your favorite chocolate chip cookie recipe? I bet you could ask that question to 5 different people and get 5 totally different recipes… brown sugar vs white sugar, cake flour vs all purpose, dark chocolate vs milk chocolate. All of these recipes result in a chocolate chip cookie but the process by which we get there is a matter of personal preference. If you were to ask multiple developers to solve a problem, it’s doubtful that any two developers write identical code. It’s not that any one solution is necessarily better than the others… the resulting code is likely just a matter of personal preference.
Overstuffed View Controllers: a problem that is universally despised by iOS developers the world over. Who hasn’t had their eyes glaze over while staring down debugging a 3000 line VC? View Controllers can control so much information, and Apple seems to have very few opinions on where specific logic should go. They give us the decision making power. How can we prevent against this annoying problem and modularize our apps better? Model–View–View Model (MVVM) can certainly help with this, but ultimately leaves routing to View Controllers, which doesn’t make the most sense. This is where a Coordinator comes in.
Kotlin is a JVM language that hit version 1.0 about a year ago (February 2016).
It is developed by JetBrains, the same people who make my favorite suite of
IDEs. The language itself is open-source under the Apache License 2.0 and is
developed as a community project over at kotlinlang.org. Kotlin is something
that I have become rather excited about over the past year. This post’s goal is
not to teach you Kotlin but to get you excited about it!
There are a lot of APIs out there, a lot of networking layers, a lot of abstractions, I’m going to offer just one way to start building Swift models backed by a RESTful API. Out of personal preference, PromiseKit will be used instead of callbacks and ObjectMapper will be used to convert between JSON and Swift objects.