Tuesday, April 28, 2015

Users vs Developers (aka Native vs Hybrid apps)



Having empirical evidence that hybrid apps are not the way to go (Facebook , Linkedin , Flipboard, Yahoo ),it is quite interesting to see how many companies still want to implement their ideas as hybrid apps.
Why? There’s only one reason I kind think of: Developers, Developers, Developers.


I am convinced that the only reason is that, Developers convincing people to make hybrid apps.

Why? Because there are thousands of developers who do not want to leave their comfort zone. Actually, it is the whole software industry that is avoiding to leave the comfort zone.


Today there are many good ideas poorly implemented receiving user rejection.
We need to leave our comfort zone, the final user (our customers) are telling us to do so.

In GeneXus, we left our comfort zone in 2009. At that time, the easiest thing for us to do was to create a generator for hybrid apps. We even evaluated PhoneGap at this point, but then realized that the real innovation was driven by Android and iOS, UI patterns and responsiveness. 

And we realized that Hybrid apps were not the best option. We decided to create Native Mobile Application generators based on our model, to extend it. And it was hard, hard work, but we believed it to be the right way for delivering great apps. It was, and it still is.
There’s a huge difference between looking like a native app and actually being a native, and user notices it. That's simply because, although Hybrid Apps may look the same, the real user experience is significantly inferior.  
The goal of an Hybrid app is to try to match native apps; while the goal of a Native app is to amaze the user with the right user experience and innovation.
So the Hybrid apps path is a never-ending race against the innovation. 


How can you tell if some’s app is Hybrid?: Tell me how you scroll and I’ll tell you who you are.


Obviously going Native does not mean success, Native is simply an ingredient of success. And this is happening today, maybe in the future this will change, but not in the near future.
So...


Users, Users, Users


We as, as a part of the software industry, should focus mainly on final users: how to solve users problems, what is the best experience for them.If you are reading this and you are an entrepreneur, my advice to you is: "do not be swayed by an hybrid app". You will spend twice the time and the money, first by the hybrid solution itself and then when your competitor releases a Native app that will force you to create a Native app yourself. (DRIFT)


If you are a developer, LEAVE YOUR COMFORT ZONE NOW. Users do not want an app where the user experience it’s not smooth or even different to what they expect to feel natural.
Sure, with building native apps new problems come along, like the amount of developers you’ll need or the budget. Try find a solution outside the HTML world, obviously I choose GeneXus for creating native apps. ;)

But even if you do not use GeneXus, there are other options that I think will be cheaper than something hybrid for you in the long run.
We have to plan and provide quality solutions to end users. We as software industry should move our decision from Developers, Developers, Developers to Users, Users, Users!

Thursday, January 2, 2014

Offline Applications and Occasionally Connected Applications



One of the main features of GeneXus Tilo is what we call Offline Applications.



Some time ago (around June or so) I told Gabriel (our Marketing Manager)  that we had been working on a feature no other tool has: automatically generating an “occasionally connected” architecture for Smart Devices applications. And I added, “more on this in a blog post I’ll write soon”.

For several months I had this pending action in my inbox ;) And yes, today I’ll explain why the architecture we are generating for our SD apps is unique.


What we mean by “Offline Applications”



This feature aims to solve two different scenarios:


1) “Occasionally connected” applications (e.g. Mobile Point of Sales apps)


From an architectural point of view it’s an application that uses data from a remote database or centralized system, but does not always have access to the it (e.g. because the app is used where there is no Internet connectivity).
When these apps cannot reach the remote database, they use a local database stored inside the device, and in some way (periodically, event driven, user action) synchronize their local data with the main database (by pushing any updates to the server and receiving any changes).


2) Full Offline applications: (e.g. Metro Application | Printed Guides apps )


These applications never use data from a remote server, they work with only a local database.


Why is GeneXus unique?



The second scenario is the easier one, but nevertheless I couldn’t find another tool that generates all the needed code. GeneXus automatically generates the sqlite database and the BL to access it in Android (Java) and iOS (Objective-C). But, as I said, this is a rather simple scenario and another tool with the same capability may be out there.


The first type of applications is where GeneXus adds even more value by automatically creating an Occasionally Connected Architecture. I’m pretty sure that GeneXus is the only programming language that generates all the code needed to implement such a complex scenario.


In 2004 Microsoft published a great article explaining what you should consider to create this kind of architecture. To be brief, it is not an easy task, even for an expert programmer. Let me enumerate what we generate for each app:


  • The remote database (e.g. Oracle, DB2, Informix, MySQL, SQL Server) and all the server-side code (Data and Business logic layers) in your preferred language: Java, C#, Ruby.
  • The client database (sqlite) and the client-side code to access it in Objective-C (iOS) and Java (Android).


But that’s just part of the story, we also provide:


  • The Synchronization Process
    • Send information from the Client to the Server
    • Receive information from the Server
  • A Service-Oriented approach to the sync process.
    • Favoring asynchronous communications: we had to implement synchronous-like communication on top of an asynchronous infrastructure.
    • Managing data send and data receive criteria: when to send or receive the data to and from the server.
    • A “store and forward” mechanism to send information to the server. We store database transactions as “messages” in the device and arrange these messages in queues while the client is offline. When connectivity is reestablished the queued messages are sent to the server for processing.
    • Consider that primary key and foreign key values on the server side can be different than in the client (due to autonumbering) for sync algorithms.
  • A Synchronization API to programmatically query the state of the sync process (pending messages, synchronization errors, etc).
  • Preloading mechanisms.
    • Many apps need to have preloaded data to avoid downloading a lot of information on first launch. For example, in an app for an Event you could ship your application in advance with embedded information about the speakers, countries, locations and automatically sync information about conference sessions when it becomes available later.


We are still working in many areas but the hard work is done. We faced many problems, and learned a lot in the process. Luckily, those lessons have been applied to the generator, so that GeneXus users who need to build this kind of apps don’t need to trip over the sames problems (such as the particulars of sqlite transactions or memory constraints in Android).


The great thing about all this is that you just need to specify some model properties to generate an application with this functionality.



But, wait a second:
  • Is it possible to have a hybrid application where some parts show online data while others use local data?  YES
  • Who designs the schema of the local database?  GeneXus, automatically!
  • Can I filter what information is sent to the clients? YES


You've probably already noticed that I’m very proud of what our team has achieved here. YES I AM. And as I said to Gabriel, I do think it’s a unique feature.


If you want further information, we cover all the functionality details here.

Happy New Year!







Tuesday, August 13, 2013

Thoughts about "The future of programming"





Bret Victor, in this excellent video, told us to think about the way we are programming today.

I'm really glad to have this chance to muse about this because in the ongoing “mobile revolution” a lot of new tools have appeared, all of them following the same programming paradigm: basically procedural, focusing on HOW we do things instead of on WHAT we want to achieve.

Since the beginning GeneXus (a programming language created by Nicolás Jodal and Breogán Gonda) has had a different paradigm. Breogán and Nicolas were probably influenced by different languages that appeared at the time. As Bret said, there was more variety because the “correct way to do things” was not yet established.

The influence of “goal-oriented” languages ​​is evident in GeneXus. It was always clear that WHAT is quite more important, in the long term, that HOW. The GeneXus model focuses on WHAT from the beginning, and always emphasized “declaring” over “programming”.

Breogan always say that GeneXus is a Knowledge-based development platform.

Knowledge-based development has two premises that other languages don’t have:
  • Capture WHAT information the user wants (user views)
  • Infer information based on these user views.

In GeneXus we have remained steadfast on not incorporating programming practices “oriented on HOW”, and evolving on a different path instead. From its point of view, the 3rd generation languages of today (with their relatively low level of abstraction) are not very different from the binary code of yesteryear.

Some very specific things you can do in those languages may not be achievable with GeneXus; however the things you do in GeneXus will be useful over time... generating COBOL code one day, and Objective-C code decades later.

GeneXus has long resisted object-oriented trends, prioritizing declarative techniques based on data and rules instead. Things like threading, exceptions, locks, &c do not belong in GeneXus, because we believe those are part of “HOW-space”.

I’m a GeneXus development team member and I don’t think GeneXus is a perfect language. However, I do believe that most of its principles are sound, and lead to a different programming paradigm. In fact, I’m expecting (and hoping) GeneXus will be an inspiration to create software in a different way in the future.

Again, I loved this call to think about the world of programming. I did it ;)

Wednesday, March 6, 2013

8 reasons why Model Driven Development is great


8 reasons why Model Driven Development is great

This article was inspired by some conference talk with some prospects that basically are worried about the dangers around Model Driven Development, which really started me thinking.
I believe there are many articles written about the dangers of Model Driven Development (MDD), many of them have valid points and some others are more of an historical and repeated nature, not taking in consideration the current developments in this area.

You'll hardly find articles saying "8 reasons because writing code manually is very dangerous", surely there are more than 8 and I was almost tempted to write some of them down. Model Driven Development has many dangers many of which come mostly from not understanding its real value. Thus, while recognizing that a number of risks written in many articles are real, I would like to enumerate some of the good things about MDD.

1. MDD actually introduces a lot of flexibility

Indeed, MDD introduces a lot of flexibility for companies and businesses. Flexibility means responsiveness to change, adaptability, both in the technical side and in the business side. If  you choose a language and hand write a solution, you may have a type of flexibility (related to power in the chosen language? ) in the short term but you are adding a lot of rigidity in the long term. So you have to take into consideration the time you want your investment in development to last, before defining which way to go.   

If you chose Silverlight, Flash, Visual Basic, Fox in the past and now you need to
create HTML5 or iOS applications: How flexible are you? How many
concepts can you reuse from your existing code? If any.


When coding by hand all you have is code, which you may but -most likely- may not reuse. In a Model Driven Development you have a model and you can reuse concepts. People creating an Android app from its FoxPro Win model are the ones who have the most flexibility in the long term.

So, Is MDD flexible? It depends. If you are a businessman or a company planning to stay in the game for the long run, then yes, Model Driven Development it’s extremely flexible.

2. Modern Models have great extensibility

Today there are models with a great extensibility at different levels and are designed to interact with hand-written code at all levels. What commonly happens is that much of this code in the medium term (if it is really very common) is incorporated into the model at some point. There are no perfect models, but many of them are useful and with great extensibility. The trick is to find a way that has the productivity advantage of MDD and the possibility of extending it when modeling is not enough.

3. Programmers can focus on what instead of how

It is great to allow people -who know absolutely nothing about Objective-C- to create business applications for iPhone and iPad that conform to the Apple guidelines, based on a model. A model that can also be used to generate apps in Android, BlackBerry or Windows 8 if required, with marginal effort. It's fantastic!

4. There are MDD platforms that support version control & continuous integration

Contrary to traditional complains against Model Driven Development, it really can support version control, collaboration, and even more. For example we have been working many years to achieve this status, and it’s fantastic to have a full version control system integrated with continuous integration tools.

5. There are great tools embracing MDD

Almost any industry uses software to increase productivity, and improve efficiency and efficacy in all operational levels, it’s an obvious approach of using software.

But the software industry is the only industry that refuses to create software using software to achieve the same goals: increase productivity, improve efficiency and efficacy. Luckily there are many companies working in a paradigm shift.

The only way to do the paradigm shift is by creating more amazing tools that create software using software.

6. The requirements team needs to focus only on the business-side

The requirements team can focus on the business side, without having to see the technical side.
It is often true that a requirement can not be met for example in a particular way due to model limitations, but this is also true in a hand coding solution!
If I request for a form with a scroll inside another scroll in an Android solution, this hardly can be accomplished and that's not because of Model Driven Development.

Because, as I said before, a big advantage of the current models is its interoperability with manually written code the worst-case scenario is to have to write something by hand, which does not invalidate most of the cases, in which the teams only need to focus in the business-side of the equation and not on how to program a particular solution.

7. Sell the solution, not the MDD paradigm

MDD is a way to create a solution efficiently, you don't need to explain MDD to the final customer, he will reap the benefits of it.
Anyway you could say that  your solution is going to be extremely flexible in the long term and that you are saving a lot of business knowledge (represented in models) for further use.

8. Technology evolution is not a worry anymore

If you have a business, you probably want to use the best technology at any particular time, but you will probably lose your focus if you need to worry about any new technology details.

Using a Model Driven Development approach you just need to focus in the model of your business, not worrying about the continuous, trending changes of the underlying technology.



So, that was my initial take on the subject, but it’s a list of reasons that can be improved.
Here Johan den Haan has more reasons to start using Model Driven Development.

Monday, March 4, 2013

Do The Harlem Shake & GeneXus Evolution 2 Upg 3

A new upgrade of GeneXus Evolution 2 (Upgrade 3) is coming.

As always this upgrade brings improvements on several areas such as usability, performance and robustness.

However in this upgrade for mobile generators we have been adding new features to create sophisticated mobile applications.


I like having fun trying out the new features. And the best way to do it is by creating some small application.

This time, because I could not get my teammates do a Harlem Shake video, I decided to create at least one Harlem Shake application ;). Basically a simple one with a catalog of Harlem Shakes, a ranking, you can find some particular one or shake your phone for a random new Shake, etc

A  feature included in this release is the ability to easily create an application with the Navigation Side pattern. This pattern is used in applications like Facebook, Gmail, YouTube, Zite, etc.. (For more about the pattern, see the Android UI Patterns blog entry).

Thus, the first thing I decided is to add this pattern to my application. This is done in GeneXus by simply setting the property to Navigation Style = Side. In this case I used this navigation style for iOS application and left a Tabbed navigation for Android.




I remember I wrote this article 2 years ago saying that Model Driven Development is slower in the initial steps but at some point you start having a more sophisticated model that covers a high percentage of applications requirements faster than coding by hand.


In this Upgrade 3 we started talking about things like transformations, effects for entering and exiting and now you can do sophisticated things using similar concepts to the ones you use when you for example change the border of a table or the color of a button.


Effects, transformations, animations, gestures are elements that we must use with care in order to create an application that is easy to use.

In U3 effects are added in the model without necessarily interfering with the programming model.
For example, if I have a call to a Panel A, the enter and exit effect of the panel are specified declaratively in a Theme.


In my application I added the Harlem Shake Curl effect to show a panel with a Harlem Shake.
So you shake your phone and the application shows a new Harlem Shake panel using a Curl Up effect and the panel exits using a Curl Down effect.



Not only UI elements were incorporated into the Upgrade 3. One extremely interesting feature that was added was Google Analytics, so you can use it in your applications to know what is happening with your application after release.

Adding this feature to your app is really easy just setting a property with an Id given by Google Analytics.
As you can see Analytics is telling me my app is not trending yet ;).




By the way I did this application in 4 days for Android and iOS and my friends from i+Dev uploaded it to the stores, even though there is someone in their team who doesn’t like my great background image ;)



You can download it now from Google Play or from appstore for iPhone or IPad

Thursday, July 26, 2012

Creating an External Object for the iOS generator

As Gaston explained in a previous post, one of the mechanisms for extending the model, is the use of External Objects. By creating an External Object you can provide functionality that is not provided by default by GeneXus.

The problem to be solved

Recently I needed for a project to interact with the actions of a panel, in a way that is not the default. There were basically to possibilities: to hack the solution into the GeneXus libraries, or to create an External Object to provide the functionality. We decided to use the later.

What I needed, was to be able to display the low-priority actions in a panel where the navigation bar is hidden.

Some background here. When you create a Smart Device Panel in GeneXus, you can define actions, which have a priority: High, Normal or Low. The low-priority actions are displayed in an action sheet, that is presented from a button in the navigation bar.

The problem was that the navigation bar was hidden, so the user didn't even see the button to show the action sheet.

Creating a new External Object

The implementation of an External Object consists on three parts:
  1. The implementation of the functionality, in Xcode
  2. The GeneXus object that defines the External Object's API
  3. The mapper, that translates the name of the GeneXus object to the Objective-C class.
Defining the methods in GeneXus

Lets start by creating the definition. To do that, in your GeneXus KB, create a new object of type "External Object" and give it a name. In this case, the object is called EOActions.

After that, you need to define the methods of the External Object. In this case, it has only one method named "ShowLowPriorityActions" that doesn't receive any parameters and has no return value.

Important: every method must be declared as "static" in the method properties.

Implementing the External Object

The implementation is of course in Xcode, since we need to create a library.

So, open Xcode and create a new library project.

Add a reference to the GXFlexibleClient.framework.

The main class implementing the External Object must subclass GXActionExternalObjectHandler (you'll need to add an '#import <GXFlexibleClient/GXFlexibleClient.h>' ), and it must provide two methods:
  • + (BOOL)canHandleAction:(id <GXActionExternalObjectDescriptor>)actionDesc
  • - (void)actionExecuteWithContext:(id<GXActionHandlerContext>)context delegate:(id<GXActionHandlerDelegate>)delegate
In the second one, don't forget to call [super actionExecuteWithContext:context delegate:delegate];

After that, you need to provide your custom implementation, and once you are done, you must call either one of:
  • [self onFinishedExecutingWithSuccess];
  • [self onFinishedExecutingWithError:error];
depending on the result, so the actions that are after the External Object call, can get executed.

After you compile the library, you need to copy it to the GeneXus KB. It must be placed in
  • <model_dir>\mobile\iOS\<main_obj_name>\iOS\Genexus\UserControls
so it gets copied when compiling and liked against.

Mapping the External Object name to the implementation class

The last piece, is the source file to provide the mapping between the GeneXus' object name and the class implementing it.

The class must be named GXCustomExternalObjectsMapper, and has only one method:
  • - (NSString *)externalObjectClassNameForObjectName:(NSString *)objName;
that receives the name of the object and returns the name of the class.

This sources (GXCustomExternalObjectsMapper.h and GXCustomExternalObjectsMapper.m) should be placed in
  • <model_dir>\mobile\iOS\<main_obj_name>\iOS\Genexus\Classes
Example implementation

I know this may be a little intimidating at first, but once you've done an External Object, you'll see it is not too difficult. It involves only this three steps as described above.

I've uploaded the XCode project, the GeneXus External Object export (as a .xpz file) and the mapper class to a GitHub repository, so you can play with the code.

Thursday, June 7, 2012

Designing on the mobile era


We are once again facing a design challenge: creating applications for new platforms we are not fully familiar with yet. This is the same situation we experienced when we jumped from a text-based UI to a Windows UI, or from Windows to the Web. The new platform is, in this case, “smart devices” (phones and tablets).

From Unconsciously incompetent to Consciously incompetent

The main point we need to realize is that we need to move outside our comfort zone and accept we are, most likely, “unconsciously incompetent” in terms of Mobile design. Even if you are a Web design expert! But don’t feel bad about it, because almost everybody is.

Things we must know to move to a “consciously incompetent” state:

  • Web Design is not Smart Devices Design
  • In most cases “One Design Doesn't Fit All” (form factors, sizes, densities, orientations, modes, etc). You could try adaptive layouts but that won’t be enough in many cases.
  • Platform Guidelines matter
    • Win8 != Android != iOS
  • UX Patterns are key on mobile design

From Consciously incompetent to Consciously competent


I'll write some essential point to move to a consciously competent state.

The basics:

Some more specific ones, but basics anyway:
  • Data Entry
Users are not too keen on custom data entry controls, so try to use the standard ones. By the way, avoid data entry if you can ;)
  • The main input today is touch. Controls on the screen should not only be touchable, but also have minimum dimensions for making it comfortable. See Touch Interaction Guidelines
  • When designing layouts for iOs (it almost applies to Android too) consider using the 4px pattern
  • Do not put many tabs on screen, remember that more is less.
  • For grids, consider using the “empty dataset pattern”.
  • Multiple layouts should be considered, normally one by size (small, medium, big).
  • Avoid using the virtual keyboard whenever possible.
  • The color scheme must be the same throughout the application.
  • Windows 8 apps must use a “chrome-less” design, so no action buttons on layouts.
  • For Android and iOS, consider using the application bar whenever possible; do not create your own way to handle actions.
  • Read about patterns that already work in many applications:

And the last and most important thing: create your first application in each platform, it is the best way to become competent.

From Consciously competent to Unconsciously competent

We could reach this status as we do in any other activity: by exercising a lot! We simply need to create a lot of applications until the best practices become second nature to us.

By the way, if you find some useful sources for learning more about design, please drop me an e-mail or just comment on this post.

@gmilano