Feb 19

What Facebook says about HTML5 mobile apps

“We’ve tried in the past to just build web apps that we could wrap in thin native wrappers, but it doesn’t work. […] Anytime somebody tries to reimplement a native widget using HTML, CSS and JavaScript it always feels like shit.” – Tom Occhino while introducing Facebook’s new React Native

It’s exactly my experience since I started developing mobile apps four years ago. Therefore, I focused on Appcelerator Titanium which does for years what Facebook tries to do now.

Nevertheless, at the moment I’m developing a BlackBerry 10 app using HTML5, and I’m quite satisfied with the outcome – but only because it’s a relatively small app that only needs to store small amounts of data on the device, and where small UI glitches are acceptable.

But in the end, there are UI glitches. Like a bar at the top that should be fixed, but scrolls with the content for a small moment before it’s being placed at the top again. Or small, subtile differences in transition animations. On the other hand, I like that I can control the UI as much as I want – since it’s only HTML that can be modified at any time using JavaScript.

So it’s as always: there is no “one solution that rules them all”. HTML5 apps are fine in several cases. But if you want to develop huge, complex apps I’m sure an approach like Titanium is the better way. And if you want to synchronize with Notes, you need to do it in Titanium anyway, so that you can use DominoToGo.


Jan 20

Working with WebSQL in an HTML5 mobile app

I wrote some days ago that I now work on a BlackBerry 10 app using BlackBerry WebWorks, which is basically Apache Cordova (Phonegap).

The app needs to read data from JSON sources and store it locally, so that the app works offline. So I need local storage, and although the WebSQL specification came to an end, it’s supported in WebWorks, Chrome and other platforms.

Working with WebSQL is relatively straightforward because in the end it’s the well known SQLite in the backend. But, you have to deal with callbacks. For example, to write stuff you’re using this kind of code:

// size in bytes, for example 1024*1024*1
// params may be an array of data for the sql statement
var size = 1024*1024*1;
var db = openDatabase("mydb", '1.0', "mydb", size);
var f = function(tx) {
  tx.executeSql(sql, params, function(transaction, result) {
	// success, do something with the result
  }, function(tx, e) {
     // failure, error is in e.message
  });
};
db.transaction(f);	

So there are two callbacks, one in case of success and one in case of error. If you want to execute multiple statements at once, you can put them all into one transaction. In that case you have to do some work to handle the results and errors. Something like this:

f = function(tx) {
	var hasError = false;
	var errors = [];
	var results = [];
	_.each(sql, function(singlesql) {
		tx.executeSql(singlesql, params, function(transaction, result) {
			results.push(result);						
		}, function(tx, e) {
			// failure
			hasError = true;
			errors.push(e.message);						
		});	
	});
	// do something with the result
};

(Note: _.each() is a method of underscore.js framework.)

Unfortunately this does not work reliable. Do you spot the error?

The function iterates though an array of sql statements, and each statement is being executed and in the result callback the result of that statement is added to a result array.

But what happens if you want to use the result array right after the _.each() loop? You’re using the result array before all the callbacks from the sql statements has been executed! So it may be null or contains only some entries, but not all.

You need to work on the results only when all sql statements have been executed:

f = function(tx) {
	var hasError = false;
	var errors = [];
	var results = [];
	var len = sql.length;
	for (var i = 0; i < len; i++) {
		tx.executeSql(sql[i], params, function(transaction, result) {
			results.push(result);
			if (i == (len-1)) {
				// do something with the result HERE!
			}			
		}, function(tx, e) {
			// failure
			hasError = true;
			errors.push(e.message);						
		});	
	};
};

In a real world app that may get cumbersome when you do lot of work with WebSQL. Therefore I started to write a framework, just like I always do when things get complicated 🙂

What about this code:

b = new JBUDatabase("mydb");
// create table if it does not exist yet
db.createTable("tickets", [ {
	name : 'id',
	type : 'TEXT'
}, {
	name : 'title',
	type : 'TEXT'
} ]);
// create a demo array of data for 100 tickets
var data = [];
for (var i = 1; i < 100; i++) {
	data.push(["ID "+i,"ticket title "+i])
}
// write the data to the WebSQL database
db.writeEntries("tickets", data);

All the WebSQL stuff packaged in a simple to use API. Much more clear, isn't it?


Oct 09

Just ordered a Blackberry Passport instead of iPhone 6

So far I’ve used an iPhone 4S and I’m still happy with it. Nevertheless, time nags on the 4S and it’s not really capable of running iOS 8 (which I will only start to use when Mac OS Yosemite is available, by the way).

So I prepared myself to spend a lot of money on a new iPhone sometimes in the next weeks.

But yesterday I saw a Blackberry Passport while working at a customer’s office. The form factor is unusual, but not bad – not bad at all. The more I played with it, the more I liked it. And the final nail to iPhone’s coffin was that the customer needs me to build a Blackberry 10 app with Appcelerator and DominoToGo – which means I need a device to test the app anyway 🙂

So I just ordered the Blackberry Passport. And I’m really looking forward to use it. Especially because

  • It has a hardware keyboard. I never get really used to the onscreen keyboard of the iPhone where I still make type errors every single time I’m writing something.
  • Using the keyboard as touchpad as well seems to work really good.
  • It has a hardware keyboard.
  • The Blackberry Hub seems to be really useful.
  • I like the square screen size because I don’t need to turn the device in order to read longer texts.
  • Did I say that it has a hardware keyboard?
  • The Blackberry 10.3 software looks really good.

 


Mar 21

New Apple Website about iPhone and iPad in the enterprise

This new website from Apple contains a lot of well structured information about using iOS devices in the enterprise. Click here to open Apple’s “New IT” website.

And you know, if you want to create custom enterprise apps my recommendation is to use Appcelerator Titanium and DominoToGo, do you?


Jun 14

More experience with developing Appcelerator Titanium mobile Apps (Alloy, Performance…)

Note: this post has been migrated from another blog. Some links may be broken.

Recently I got a new project to develop a mobile app as frontend for a complex IBM Notes application. Target platform is iOS first and Blackberry 10 later, maybe even Android. The customer selected Appcelerator Titanium as platform and Domino To Go as framework for working with IBM Notes data. Offline capability with storage of relatively big datasets was mandatory, so any mobile web or hybrid approach was out of the game.

I know there are posts in the Web
saying how ugly Titanium is, how many problems it has et al. From my experience, all of that is not true, at least not today. The Titanium development environment works smooth and stable, every API works as it should. The API documentation is very good, and Appcelerator even offers a lot of additional documentation for topics like how to setup the native SDK for iOS, Android and Blackberry 10. Furthermore, the Q&A section of Appcelerator’s website is excellent and a reliable source for solving development questions.


Since I know Titanium for a long time now, I’m aware that in the early days of Titanium things were completely different. There were lots of memory and stability problems and documentation was poor – but as I said above, all of those problems are gone, at least in my experience.


And most importantly, I like the approach of using simple JavaScript to access native APIs across all platforms. It spares the huge learning curve of Objective C for iOS, Java for Android and whatever for Blackberry 10. And, you can have the same codebase to deliver an app for all platforms.


The new Alloy model-view-controller framework of Titanium is a great addition, too. It allows to seperate UI definitions and data models from business logic, and it’s well engineered, clean and logical. In Alloy, the UI is defined with simple XML code, which is transformed to traditional Titanium JavaScript code automatically by the Alloy compiler. It allows you to work with stylesheets and to create your own UI components for re-use in the same project or in another projects.


When working in an Alloy Titanium project, you are motivated to modularize your code with the CommonJS technique, which is also a good thing because it prevents namespace issues and offers a well-established system to split your project into manageable pieces.


In that project, the customer uses Domino To Go to synchronize about 100.000 datasets from Notes views to the device, so they can be used offline. There are three components that take time during the synchronization:


1.) Domino To Go on the Domino side needs to run through the view, read view entries and build JSON data.


2.) The device needs to download the JSON data from Domino.


3.) The JSON data needs to be processed on the device to transform then into a NotesView-like data structure and store it in the SQLite database on the device.


First, a full synchronization took more than 3 minutes in the simulator. After some optimization, we managed to bring this down to about 40 seconds. After the first full synchronization, caching techniques are used, so next synchronisations will be even faster.
But, from my point of view, 40 seconds for about 100.000 view datasets is not that bad after all 🙂


The only ugly thing
with developing a native iOS App is the amount of work needed to be able to deploy the app on test devices first, and for the enterprise distribution later. To deploy on test devices, you need apply for the Apple developer program, which can take some days until Apple checked and processed your application. Then you need to understand their system of provisioning profiles and all the certificates you need.


For every test device you need to get it’s UUID, enter it in the member area of the iOS developer center, create a new provision profile, download it and install it on the Mac. Sure, you will do this work seldom, only when you got a new test device, but for new developers, it takes some time to understand this procedure.


But the Apple procedures have nothing to do with Titanium. I think, Titanium is a very good choice to develop native mobile apps. I like mobile web apps, too, but so far, I like working with Titanium better.


Apr 08

Appcelerator Titanium 3.1 and Domino To Go is getting faster – and brings official support for Blackberry 10

Note: this post has been migrated from another blog. Some links may be broken.

If you think about creating mobile apps, Appcelerator Titanium is my recommended tool. In case you don’t know about it yet, I strongly suggest taking a look at it.

The upcoming version 3.1 brings notable performance improvements in all areas:

  • an average 20% performance improvement for iOS apps
  • an average of over 30% performance improvement for Android apps
  • a replacement for the TableView control, which is multiple times faster


Futhermore, support for Blackberry 10 devices gets into an official beta phase with Titanium 3.1.

Beside that, Titanium 3.1 delivers a lot of additional features like:

  • support for Facebook V3 API
  • support for Google Maps V2 API on Android
  • support for Newsstand API on iOS
  • support for NFC on Android
  • support for calendar events and reminders on iOS (EventKit UI Framework)
  • updates to the Alloy framework (model view controller framework – seperates design from data and logic)


and more.

I’m working with Titanium for quite some time now, about two years. And in that time, Titanium made and impressive progress. I still think it’s far superior to the HTML5 approach, mostly because in the end, you get native apps that look & feel native and that are full offline capable.
And, if you need to work with Notes and Domino data in a mobile app, you can use Domino To Go.


Mar 18

My Framework for Mobile Web Apps, based on Dojo Mobile

Note: this post has been migrated from another blog. Some links may be broken.

As requested by one well known fellow of the community I’d like to tell you about my own framework for mobile web apps, based on Dojo and XPages:
Some time ago a customer requested me to build XPages components for mobile web apps. The idea was to enable other developers to build mobile web apps with XPages, but without struggeling with Dojo Mobile themselves.

I briefly looked at the Mobile Controls from the Extension Library, but they didn’t suited me, so I started building my own controls.

As of today, the framework consists out of these controls:

To create a page, for example to host a view, I create a new custom control and include for the m_ccCommon_page.
That control provides several editable areas (faces), in which I can for example place a m_ccCommon_view control to display a Domino view.

Let’s have a look at this page:

And source code for this page is this:

Or this page:

has this source (see attached file ‘source1.txt’ below)

Now let’s have a close look how to use the m_ccCommon_view control:

To display a view in the mobile web app, I only need to tell this control about

– the name of the view to use
– the name of the column to display (multiple columns not supported yet, because screen estate is limited on a mobile device)

– optional a column name to get icons from (standard Notes icon columns are supported)

– if row numbers should be displayed

– if a search bar should be displayed

– if a fulltext search should be limited to certain fields

– how many characters are allowed in one row before the row’s content will be shortened with “…”

– to to which page to navigate when a row was clicked

and I don’t need to think about all the technical details at all.

Or, to create a page with a toolbar, I only need this code:


There are some more goodies in this framework, like multiple partial refreshes so that when something in the content area changes, the content of the toolbar can be changed automatically, too.
The framework works fine with Dojo Mobile 1.7 (Domino 9 beta) and will be even better with Dojo 1.8 (Domino 9).

Most certainly, the framework is not perfect and doesn’t cover all usecases, but it contains a lot of easy to use stuff and could be extended easily. So if you plan to create mobile web apps with XPages and Domino 9 and you want to save some development time, ping me a jbuss at julianbussnet or via skype (skype name. julianbuss). I am not in the position to make this framework free, but if you buy some consulting hours, we can talk about getting this framework, too.


Mar 12

Q&A: what is the best way to create mobile apps for IBM Notes?

Note: this post has been migrated from another blog. Some links may be broken.

I got the following question from a Notes developer trying to find a way to do mobile Apps:


Hello Julian

i’m developer to lotus notes application.

Currently, I have developed simple application with XPages Mobile Controls, for display in the mobile.

The application has a menu, a view with documents and a form to display data


I would like to know, what is the best development environment, to make the application runs in the phone in offline mode.


I’ve been looking and have found two possible solutions.

PhoneGap (used in demos openntf) and Titanium (youatnotes) recommended by you.


I would like to know the pros and cons of each option.

And the titanium platform costs as PhoneGap is free.

and if there are demos, tutorials, videos, courses ….. to learn.


Thanks in advance


jose



And this is my reply:


Hi Jose,


if you talk about offline mode, you really need to think about creating native apps instead of web based apps.


You’re thinking about Phonegap. I checked Phonegap some time ago – in a nutshell, it wraps a web app into a native browser component on the mobile device. Furthermore, Phonegap adds some APIs to access sensors and other hardware features of the mobile device via JavaScript.


Without any doubt, Phonegap is a good tool. But, in the end, you’re developing a web application that tries to look and feel like a native app. There are examples out there where mobile web applications works very good.

But in my opinion, developing a web application that behaves perfectly on a mobile device is very hard.


I tried the XPages mobile controls from OpenNTF and experienced a lot of imperfection with them. Bumby transitions, controls that try to look like native but fail to do so in important details, a style of coding to make it hard to develop big and complex applications and so on.
Then I developed a set of mobile controls on my own, based on Dojo Mobile. I managed to work around many issues and limitations of a mobile web app, but still, my results are far from being perfect when compared to a native app.


But, even when putting all these issues aside, creating an offline capable app with web technologies adds a whole new level of complexity and issues. One problem is, that – at least to my knowledge – the size of local storage for a web application is very limited. So even if you are able to synchronize for example a Notes view with JavaScript in a mobile web app, you will most probably run into storage size restrictions.


So, in the end, when you need offline functionality (and I’m pretty sure you need it for most business applications), you will have a very hard time to implement that with a web app, and that rules out Phonegap.
Plese note that maybe things changed in the last months and all I said above is wrong. If so, please correct me.


Assuming all I said above is correct, there are two options left for you:


1.) Creating native apps with the native development enviroment (like XCode and Objective C for iOS).


2.) Creating native apps with Appcelerator Titanium (which is free in the basic edition, by the way).


The first option is the best if you’re willing to learn the development enviroment and the language. But if you’re familiar with stuff like HTML, JavaScript and LotusScript at the moment, I bet you will have a very hard time to learn Objective C.

That leaves option 2 as the only remaining option.

With Appcelerator Titanium, you’re writing native apps with JavaScript. The apps are using all native controls, they look & feel native and have access to all hardware sensors, and there are no restrictions for storing local data .

Titanium provides you with good APIs to access all native stuff from JavasScript. And you can write code that works similar on multiple devices (iOS, Android, Blackberry), while keeping the native look & feel of each device. And the free edition of Titanium is great and contains everything you need to write mobile apps for IBM Notes.

Futhermore, there is a lot of documentation and community for Titanium. Learning Titanium is no problem at all if you’re familiar with JavaScript.

Lastly, if you want to work with Lotus Notes data in the mobile app, Domino To Go is the perfect extension for Titanium, because it makes working with Notes data on the mobile device very easy and familiar. You can find code samples
here in my blog.

One last word about mobile web apps: there is a lot going on in this space, like the new IBM solution for creating mobile apps, also based on web technology. I’m not very familiar with that tool, but far as I know, it’s a typical IBM enterprise product: big, complex, costs money and needs quite some time to learn.


Hope I could help,

Julian


Nov 06

Building a framework for mobile web apps

Note: this post has been migrated from another blog. Some links may be broken.

I built a nice framework for desktop web apps, based on XPages, for a customer. It consist out of ready-to-use controls for the overal layout, views, advanced Dojo controls et al. Furthermore, it includes some sophisticated and cool controls for filtering view data based on column values or categories. For example, I developed a category selector like this:



The control  is generic and reads all categories out of a view in order to display them in a tree-style dialog. It’s quite fast, even with tens of thousands of documents and includes caching of category data.
Yes, you’re right, what does that have to do with a mobile web app? Nothing so far, this should only give you a feeling what kind of desktop framework I’m talking about 🙂


Anyway, now we want to develop a mobile version of that framework, so that the customer’s developers are able to build mobile versions of their web apps.


Personally, I don’t like mobile web apps very much, but the customer wants to give them a try. I know there are some useful frameworks out there, like jQuery mobile and Sencha, but the customer needs to stay standard conform, and that means IBM XPages with Dojo 1.6. Luckily, Dojo Mobile is not that bad, too.


I’m building a high level framework so that the developers doesn’t need to deal with Dojo mobile directly at all. For example, a simple page looks like this in Domino Designer:



You see that the page simply consists out of one custom control which has some custom properties and an editable area for the content (the control has editable areas for the header and footer, too, but they are not used in this simple example).
In the mobile web this looks like so:



Or what about a navigation like this:



The source code for that page is:




As you see, no need to deal with mobile Dojo at all. A developer just needs to use some of my custom controls, set some customer properties and that’s it. Easy and effective, just as I like it 🙂


This seems to be an interesting project, so stay tuned for more blogs about it.


Jun 15

Why mobile web apps are a fail (most of the times)

Note: this post has been migrated from another blog. Some links may be broken.

First, please read this blog post from Jake Howlett, be sure to read the comments, too.

His experience is a good example why mobile web apps are pointless for many businesses: a mobile business App is for the personnel in the field. In most cases, the field will not be restricted to your own country, where you have a data plan for your iPhone, iPad, Android or whatever device.

So when you make a step across the border, and use a mobile web app, you have good chances to drive your company into bankcruptcy. Inside the EU, there is a limit for how much network providers can charge for roaming, but outside, only the sky is the limit.
And even in the EU, it’s super expensive and there is no way you can use a mobile web app with data roaming on a regular basis.

But even when you stay in your own country:

  • You go to your customer, the customer has his office deep inside a big building, and you’re doomed. No network.
  • You’re traveling by plane or by train – doomed, no or only minimal network.
  • You’re traveling by car and a collegue is driving – nearly doomed, since there are so many gaps in the network even along the Autobahn.
  • Your customer is in the country – doomed again, because there is no 3G network and the mobile web App is so slow that you just can’t use it.


The only usecase I can see for a mobile web app is when you can clearly define in which places you will use the app, and that these places have excellent network coverage and are covered by your data plan.

Am I wrong? Do I miss something?

So far, I think, mobile business apps just need to be offline capable. And if you need such an app, please have a look at our Domino To Go solution.