App backend selection

Assuming that we want to develop a simple app – e.g. the Shopping list app example that triggered my previous post – and make it available for multiple platforms (Android, iOS, and also Web to cover other devices including Windows and macOS), how do we develop the backend services nowadays? (As P2P-Web is just a dream, and cloud is all we have?)

One idea is to develop the backend ourselves, and expose it using a REST API. Fairly easy to do with ASP .NET WebAPI and Visual Studio. Even on a Mac. Then host it either on our server or in the cloud.

Yet, better choices must exist – easier to implement and skip both the development complexity and the deployment hustle – ain’t it? Indeed, there are a few good choices out there:

Studying them a bit, I think that personally I would go with Google Firebase if I needed to make a selection today, although it includes fewer cloud products overall. Because of these small reasons:

  • Google offers a small real-time database instance 100% for free and supports multiple platforms, including Android, iOS, the Web (JavaScript), and REST (for example to be used from macOS or Windows apps – although there authentication of users, such as using Facebook or Google might be trickier). Most importantly, however, Firebase provides events when data changes, which saves much development time since you don’t need to re-query the database periodically (unless you are using REST) – data changes come to your code, directly. And it seems possible to easily set up working offline too – a nice extra.
  • Microsoft Azure offers a database for free too, but as I understand this is only for a year, and maybe my app won’t be successful and I would forgot about the subscription and therefore free for life is better. Besides that it offers good features, including data syncing and working offline (with Cosmos DB).
  • AWS does have a Free tier that includes a NoSQL database (DynamoDB) but it seems their pricing system is more complicated in case we’d eventually need to scale up or use other products; moreover, syncing between client app instances and the cloud, change notifications, and working offline don’t seem to be core concerns in their SDKs (although the number of supported platforms is the highest at Amazon.)

But it’s highly possible that I missed something! I admit, I didn’t have much time to do the hypothetical analysis and offers change so often in this cloudy world (today’s picture is highly different than that of two years ago when I last checked.)

Maybe you can help with further suggestions if you have experience with some of these tools: what would you choose, and why?

Advertisements
Posted in Development | Tagged , , , , , | Leave a comment

P2P+cloud

A few days ago I was thinking that it’s really a pity that I cannot find a good iOS shopping list app in my language. Good means simple, allowing me to manage multiple named lists with check-completable items, with autocompletion on typing product names (using a built-in but adaptable list of names), and syncing to my wife’s device.

For now I use Apple’s Notes app which has everything except autocompletion. But it does sync through cloud, and there I also have other notes, not just shopping lists. It would be nice to have domain separation.

So let’s assume that I want to develop such an app. My deep question here is how should it sync data between devices?

  • Through cloud: should I just go with the traditional way, i.e. having a server API and database in the cloud to provide data to client app instances, and then syncing will be done through that central repository? or
  • Through peer-to-peer (P2P) connections: directly between devices when they are on the same network.
  • Or both? I.e. try P2P first, then cloud? (With some clever way to send messages similarly, even if P2P communication relies on different protocols than Web?)
  • Or configurable by end users? So that if I have an important list that I don’t like to be stored in cloud, but I would accept it being on my wife’s device, I could configure that only P2P is enabled.

Thinking about these issues, I found this article, about P2P-ing the entire Web. Very, very interesting. That would turn actually all the four points above into a single one, ain’t it?… (But we would need to change core protocols for that to work as in P2P communication at any given time one device is a server, i.e. accessible through an IP address, and we all know client machines are usually behind routers, firewalls and generally out of reach.)

Posted in Miscellaneous | Tagged , | 1 Comment

Next wave?

First and second steps

At first there were desktop computers:

  • either at home or at the office (later also on the go with notebooks),
  • desktop apps present complex information in 2D (or projected 3D) graphical format on a large screen, with sound, and
  • users can input data and commands with a mouse and a keyboard, that they initially need to learn how to use.

Then we had the smartphone revolution:

  • everywhere, even on the road,
  • as powerful computing components got small enough,
  • mobile apps can show fair amounts of information also in 2D format on a small screen (later also larger “tablets”), with sound, and
  • users can easily input data and commands with natural multi-touch gestures (and lately, also voice),
  • while they can continue using their desktop computers whenever mobile devices do not support certain features or scenarios (such as for development).

Third leap?

One can think about the roadmap of Amazon Alexa and similar voice-enabled devices:

  • either at home or at the office (later probably also in vehicles),
  • with help from artificial intelligence development,
  • voice apps can provide information in sound format using human language even without a screen (later probably in more languages, and with optional touch screen accompaniment), and
  • users can input a fair amount of commands naturally with their voice (and optionally some touch gestures),
  • while they can continue using their desktop computers and smartphones whenever voice-enabled devices do not support certain features or scenarios or when they are not around,
  • but unless people want to get away from smartphones themselves (like the roadmap article linked above suggests) – something that isn’t possible when they are on the road without a vehicle (I guess) – there is little actual need for these devices since smartphones can easily turn into voice-enabled devices anyway.

Finally, we have Microsoft HoloLens and similar devices of the future:

  • everywhere, even on the road,
  • as powerful computing components get even smaller, and with help from artificial intelligence development,
  • holographic apps would present very complex information in 2D and natural 3D augmented reality format directly projected on eyes, with sound, and
  • users can input a fair amount of commands naturally with air gestures and their voice, and textual data and more commands with a Bluetooth connected keyboard,
  • so they could eventually get rid of their smartphones and later even their desktop computers,
  • but the device needs to become more powerful, yet lighter and comfortable enough for end users, foldable to fit into pockets, and also get highly improved battery life (technically difficult), and end users need time to get used to wearing such glasses instead of touching phones (which would be very difficult too, I guess), and supplementary, air gestures may turn out as being just too difficult to be performed all the time by people, compared to using multi-touch screens in this regard.

As you can see, the final points of both possible directions indicated above are fairly big, so I don’t think a truly revolutionary wave 3 is going to happen soon, myself. Instead, I tend to consider these devices as interesting accessories, maybe even opening new niche markets that developers can embrace (just like smartwatches), but not more for now.

Posted in Miscellaneous | Tagged , , , , , , , | Leave a comment

Flutter

I recently found out about the new cross-platform framework for mobile development that Google backs up: Flutter. Although it’s only in alpha stage (i.e. early development) at this time, I wonder, could it eventually reach more adopters than Xamarin or Cordova-based frameworks, or – more importantly – more than native mobile development?

Here is the table I came up with to compare:

Android + iOS
native
Cordova-based cross-platform Xamarin
cross-platform
Flutter (alpha)
cross-platform
Backed up by Google + Apple Apache Microsoft Google
What you need to know/learn? Java/Kotlin + ObjC/Swift JavaScript / TypeScript C# Dart
How does it work? Natively WebView: interpreted code, rendered as in device browser AOT-compiled, uses OEM widgets, native rendering AOT-compiled, uses custom widgets, custom rendering
Stock-like UI? Yes Yes Yes Requires custom widget selection
Native performance? Yes No Yes Yes
Easy maintenance? No Yes Yes Yes
Difficult corner cases? No Yes Yes Yes
Easily access new OS features? Immediately Later Later Later
Non-mobile platform support None Web Windows None
3D support Unity WebGL None None

While I still don’t know the answer, I tend to say it’s a no.

Unless Flutter would prove to have support for many use case scenarios and very few bugs when it would go beta, which I assume will be very difficult given the fact that they do custom rendering and that developers can only use widgets from a custom catalog.

Or unless Google pushes it hard into Android Studio and “forces” everyone (or at least most Android developers) to use it, like Microsoft did with Visual Studio .NET when they wanted less Win32 development long time ago. But this time it’s different, as we have a mobile OS duopoly and Apple iOS developers could simply stick with xCode anyway!

By the way, Android Studio 3 is now live, with Kotlin language support!

Posted in Architecture | Tagged , , , , , | Leave a comment

Learning the basics of programming can and should be fun

Myself I have learned the basics of programming using GW-Basic back in early 1990s. Once I understood what programming really is – i.e. that i = i + 1 actually means incrementing value of variable i from the computer’s memory and not a mathematical equality – that simple interpreter program running on DOS became my best friend.

(Since I didn’t have access to a PC every day back then, I actually used to have a notebook where I was writing programs down whenever ideas came, eventually checking them with GW-Basic only later, but as soon as I got a chance.)

And as I recently tweeted, I found out that there is a very easy – and 100% free – way to run a similar, compatible interpreter on Windows, Mac, or Linux: PC-Basic, which – together with reading some documentation or following some Basic tutorials – can help you or your children to at least check what programming is about if not more!

Note that if you think that Basic is a dead programming language nowadays you’re totally wrong. Actually we have Visual Basic that can and is used in the .NET world within comtemporary projects, but – most importantly – even if you’d need to learn something completely new later:

The concepts that you’d understand through Basic will remain the same regardless of the platform you’d eventually need to develop for: you’d just need to build more knowledge and skills on top of the common core!

C++, Java, .NET, Swift, and many other fancy languages and frameworks rely – at their bottom – on the same computing infrastructure, made of:

  • instructions (such as assignments, aritmetic operations, performing loops, and decisional branches) to be executed at runtime;
  • memory variables holding different types of values while your programs run;
  • and controlling input and output to support communication with end users.

Sure, the newer technologies come with add-ons like object orientation, events, and so on, but it will be easy to learn about these enhancements once you master statements, variables and simple user interface handling that you can do with Basic alone.

And unlike when using an IDE, learning programming with an interpreter program is – in my opinion – a lot more fun, as you don’t feel alone since you are… talking to a bot!

Posted in Miscellaneous | Tagged , , , , , | 2 Comments

Swift selectors and number of arguments

In Swift, you can create and “perform” a #selector like below (e.g. in an iOS app) and it seems to work just fine (i.e. executes the “selected” function):

class Obj1 : NSObject {
    var value: String?
    @objc func setValue(value: String) -> Void {
        self.value = value
    }
    func run() -> Void {
        let selected = #selector(setValue(value:))
        perform(selected, with: "V")
        print(value!)
    }
}
Obj1().run() //outputs: "V"

Then you can add a new argument to the function definition like this, and running it through the selector would still work if you just add a second with argument to the perform call as well:

class Obj2 : NSObject {
    var value: String?
    @objc func setValue(value: String, suffix: String) -> Void {
        self.value = value + suffix
    }
    func run() -> Void {
        let selected = #selector(setValue(value:suffix:))
        perform(selected, with: "V", with "s")
        print(value!)
    }
}
Obj2().run() //outputs: "Vs"

But unfortunately you cannot follow the same pattern and add a third argument to setValue, expecting to be able to add another with – the code below doesn’t compile because there is no appropriate perform override available on NSObject – although the #selector expression itself would run correctly:

class Obj3 : NSObject {
    var value: String?
    @objc func setValue(
        prefix: String, value: String, suffix: String) -> Void {
            self.value = prefix + value + suffix
    }
    func run() -> Void {
        let selected = #selector(setValue(prefix:value:suffix:))
        perform(selected, with: "p", with: "V", with "s")
        print(value!)
    }
}
Obj3().run() //expected output: "pVs"; but Obj3 doesn't compile!

I assume this is mostly because such a construct would be rarely needed, so extending the library with more overrides would have just been too much overhead. Moreover, I understand that it is eventually possible to do it in a generic way by calling some lower level, Objective C library, functions. But I think it’s good to acknowledge this NSObject inheriting limitation (or should we call it inconsistence?) rather sooner than later.

Of course, if your selected function doesn’t have any argument, executing it with a selector would still work, just don’t pass any with argument to the perform call either. (Awkward conclusion: the approach works only with functions that have 0-2 arguments.)

Posted in iOS, macOS, Swift | Tagged , , , , , | Leave a comment

Avoid extracting internal libraries

In a not-too-small software development company it’s very likely that you’ll manage multiple projects over time, with multiple teams and doing work for multiple customers. And for each platform/framework that you’d target (sometimes even cross-platform) you will probably determine that you could extract and reuse common components from code written by your developers in multiple ways:

  1. By extracting common components inside an application only, to better organize and maintain code for that specific project;
  2. Packaging some components to be reused by the same team and/or other teams in the company, for the same and/or other customers/partners;
  3. Publishing generic components as separate products that you could either sell or give for free to other developers too, with or without opening the source code.

I totally agree that points 1 and 3 are very good choices.

However, I think that packaging some components and distributing them only internally in your company, especially if this is done to be reused by other teams, is not a good approach, and this is for two simple reasons:

  • When you share code internally only, you tend to document it poorly, if you do it at all. Moreover, although for developers the code is the best documentation of itself, sometimes it’s difficult for colleagues to reach the original source code of such internal components or it would require asking many questions and obtaining appropriate rights to get to it;
  • When you share code internally in a company, you must ensure that the colleagues who could use it – including the newly hired developers from your and other teams – would know about what’s available and how to use the extracted common components correctly; as at first they only have knowledge and skills for the core platform(s)/framework(s) that your components rely on too, you’ll need to train them well before they could do work on top of the super-framework solution.

What to do then? You cannot just let all teams in your company to rewrite the common things (like a generic .NET unit of work/repository pattern implementation, for example) all the time, can you?

I’d say, why not? If the customers pay separately, then it’s fine – because each implementation will probably have something specific that will fit better for the needs of the customer who requested it or those of the project that it is reimplemented for!

And if you still say it’s not OK, then just go with point 3 instead, and extract a separate product out of the common code – a generic component library – that other developers could download and for which you’ll surely prepare good documentation, usage samples, and better overall quality. Of course, if legal agreements require it, talk to your customer(s) to allow you to extract, publish/sell that library separately, providing some of the outcome to the customer(s) themselves if the cost is shared as well!

Posted in Architecture | Tagged , , , | Leave a comment