Welcome to part two of my series comparing and contrasting the many ways you can develop a mobile app. (Here’s
part one if you missed it.)
As a reminder, I’m developing an app called Ok Car – a classified ad app for buying and selling used cars.
In this post, we'll spend some time reviewing the wireframe I put together in part one. We'll also setup the "plumbing"
necessary to allow us to just focus on the mobile application itself in future installments.
Besides a few typos, the wireframe survived review mostly intact. Reviewers noted we probably should have color as a
search criteria (being red-green color blind myself I have a good excuse for missing that). The create listing screen
was missing some fields and I needed to handle a few more states (like before a listing is approved and after a car
is sold). Taking all those changes into account we have a version 2 of the wireframe here.
Now on to the plumbing chores...
more...
Why not listen while you read 😉.
Choosing how to implement a mobile app has become reminiscent of a Paul Simon song, but rather than "...slip out the back, Jack; make a new plan,
Stan; you don't need to be coy, Roy" you can "code native, David; use a declarative style, Kyhle; or code cross platform, Norm" to name just a few.
(Ok, my song writing career has a long way to go.) In fact, here is a list off the top of my head of the ways you could code an app:
- Native iOS
- Native Android
- Native iOS using SwiftUI
- Native Android using Compose
- React Native
- Flutter
- Wrap a web application (Cordova and alike)
And there are permutations of each of those choices. Should you use Swift or Objective-C for iOS native applications? Kotlin or Java for native
Android applications? Not to mention that the list of languages and frameworks for a wrapped web application is probably approaching infinity. And
now doing a web search (not just off the top of my head) there are even more – Microsoft’s Xamarin (I should have remembered that one), Salesforce
based app, Amazon’s Honeycode just to name a few.
In the end, we probably could get to 50 ways to code our mobile app, but luckily for the author and reader we can focus on a shorter list and get our
app (and blog posts) done and set ourselves free.
more...
By now I'm sure you've seen and/or heard of Apple's prohibition on using anything other than "approved languages" when developing for the iPad/iPhone.
Here's the infamous text:
3.3.1 - Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in
Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented
APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
First off, no assembly language?!? What if I want to go right to the metal and make sure my App is as small, fast and power preserving as possible. Surely this is just an
oversight. And I'm being only a little facetious. The first version of the AI code for my Cherokee Checkers game on the
iPhone was too slow when written in Objective-C. I rewrote it in straight C (saving lots of object creation and destruction) and that speed it up significantly. But I was looking
at moving it into assembler if needed - I'd like to see the objection to that.
In the end these kinds of arbitrary rules that are only driven by Apple's monopolistic tendencies will likely come back and bite them. Of course they can just drop it when
it's convenient for them, so I suppose it might even make business sense. It kind of brings a soap opera feel to the whole mobile development scene.
Just think of the old Edwin Starr tune (http://www.youtube.com/watch?v=2pIqxuygWwM) and sing along "iPad, what is it good for - absolutely something".
So far, yes to games, no to browsing while watching TV - can't have IM or another app running and it's a real pain to page down with a swipe after a while. Of course I'm comparing it to the Mac Air, which actually feels lighter. And with a notebook, I can close it and feel like it won't suffer any dog or kid damage. The iPad screen is always out and vulnerable.
Book reading is yet to be determined; it's a lot heavier than the Kindle. I hope to try that out later tonight.
It sure does look purty though.
The waiting is over and the jumbo iPhone is out. The name may be a little disconcerting to some women - http://www.youtube.com/watch?v=lsjU0K8QPhs but I suppose we'll all get used to it.
I'll start by saying I do intend to order one (after all I will be writing software for it). Apple is positioning it as a device that will fit into a niche between laptop and a mobile phone. That's the $64,000 question, is there a niche? Is this the right device for that niche? I'm actually typing this on a Macintosh Air laptop while sitting in front of my TV so I'm right on one side of the niche. The tech pundits are complaining about the lack of multi-tasking and the tethering to iTunes while the Apple fans are saying those things don't matter. As with the iPhone I think software will be the difference. (Ok, maybe I'm a little biased.) Having a developer ecosystems already trained, excited and in place will mean any App anyone could need will be available. Unleashing the ingenuity and creativity of thousands of software developers should be the goal of any platform creator. It worked pretty well for Bill Gates with DOS and Windows and I think Apple has replicated that winning combination with the iPhone, no reason it shouldn't keep things going with another device in the family.
I still think it's mobile phones that will cut into the iPad market the most. It's hard to beat the convenience of a device in your pocket or purse. When will a pad make sense? It might replace the laptop you use while sitting in front of the TV (what, you watch TV without a laptop?). Certainly for some mobile jobs that need more screen space it will be a good fit, I can see the iPad being big with Doctors for example. Maybe it doesn't seem that large a market, but just wait till all us software developers get one in our hands. We'll figure out a way to make such a cool gadget useful.
As engineers we may think our world has nothing in common with unnaturally thin models wearing odd shaped outfits preening down a runway in Paris, but as strange as it may seem technology is a susceptible to fads as any other area of human endeavor. Cloud computing is currently all the rage in our world, as anyone glancing at blogs, book and newsletters can tell you. But does cloud computing deserve the attention from the paparazzi of the hi-tech press? Or is it just a face lift covering up a paradigm who's time has passed? Let's take a look.
First, let's try to define cloud computing. As Supreme Court justice Potter Stewart famously said about a much more prurient subject "we know it when we see it". It involves moving storage and computation from a local desktop PC over the network to a server. But that's not quite enough of a distinction; the Internet has been going strong for years doing just that. I think more precisely we can view cloud computing as providing storage, computing and networking as a service that can consumed at a variable rate. It is the "utility" nature of the resources provided by cloud computing that distinguishes it from the plain vanilla client server model.
more...
