Posted over on SocialBizUg - Popover to Google Maps

A couple of weeks ago I started messing with Titanium Appcelerator. Coming from Domino Designer and Eclipse the IDE will look very familiar. It's eclipse and it's based off of Aptana Studio. I guess the biggest issue to being productive is the learning curve for the API. But honestly when is that not the case?

So starting to delve into this, Titanium apps are purely client side javascript based. You write the CSJS that builds the UI, Business Logic, Layout, everything. While this may seem daunting at first it actually makes pretty good sense I think. If like me you don't like large javascript files it forces you to think in a more OOP mindset. Now some of you are saying "but CSJS isn't OO". Au Contraire my friend. There are a couple of different ways to approach OOP in CSJS. You can have a file where each file is an Object or a Function which returns an Object. Just follow the Singleton/Closure pattern. A perfect example of OO Javascript is Dojo, just to put things into perspective. But OO Javascript is another topic for another day.

The installation of Titanium is pretty straight forward. Download the .dmg file, run the install pkg and follow the prompts. Now I did hit one snag here, when I tried to install the Android SDK it complained about not being able to find Android SDK API 19. I just deselected this and finished the installation and then updated Titanium and it selected that API 19 for me and all was well. This was really the only snag I hit. Also be aware that you'll need to download and install xCode from the App Store in order to get the iOS simulators (iPhone and iPad).

Once this was completed, I was able to delve right in and create my first 'Hello World' app and then start adding to it as time goes on. Of course me being me I figured I would use the most complicated thing I could think of as my first project. I decided to start replicating the functionality of redpill Now. This has prompted adding to the functionality of redpill Now, mainly a rather robust REST service which is smart enough to traverse a graph db. This REST service delivers all of the content needed to provide the data for a mobile application as JSON. This will also be taking advantage of the org.openntf.domino api  for iterating over collections, view entries and of course the Document.toJson functionality.

After you make changes to your code, you can fire up the iPhone, iPad or Android simulators right from within Titanium. This is a very handy feature, tho I'm still fighting with troubleshooting. The eclipse debugger is included in Titanium and it works as one would expect it to work. I think this is a very nice touch. You can also install to a device right from Titanium. I haven't tried this yet. 

So far I've been able to replicate all of the lists in redpill Now. While these lists are not yet as refined or as intelligent as the base product, they are getting there. Next in the learning curve will be posting to the REST service and dealing with forms. Hopefully in the coming weeks I'll be able to post some screen shots and code of my progress.

While going through this exercise, it has made me stop and think a bit. Looking at the Connect 2014 sessions, maybe this is a good path to start going down. I mean, the IBM Notes client is becoming less and less relevant as the years go by. Also, it seems that IBM isn't providing as much emphasis on the "Lotus" products as they once did. I'm still undecided if this is a good thing or not, but my gut tells me I need to start moving some eggs out of the IBM Notes and Domino basket. Not to mention, learning a new technology is fun and challenging. Plus, it forces you to think differently which makes you a better all around software engineer. Which is always a good thing.

OK, so today is the 2nd day I've spent with the Mobile controls from Domino 9.0.1. I must say the lack of a 9.0.1 Beta is quite obvious. So some of the "improvements" IBM made to the mobile controls are the addition of onBeforeTransitionIn/Out onAfterTransitionIn/Out. While these events are sorely needed, the implementation IBM chose to use doesn't work is kind-of odd.

So, a brief rundown of the transition events pre 9.0.1. I posted a while back about how to implement these methods in your mobile application. Short version is do a dojo.connect to attach to the needed transition event of an appPage. Then in that function make an RPC call to do any server side processing that might be needed. This initiated the following chain of events:

  • An HTTP POST request was sent that ran the RPC Method
  • The page moved to the destination page
  • onBeforeTransitionIn fired a partialRefresh to refresh the content of the destination page

This series of events still happens, kind-of, just not in that order. The events now process in this order:

  • A partialRefresh of the destination page happens
  • An HTTP POST request is sent that runs the RPC method
  • A is fired which is supposed to move to the destination page

If your content is static and not programmatically determined, this is fine. But otherwise this is all wrong. Why is a partialRefresh firing before the POST? The POST is what determines which markup is to be shown on the destination page. With the partialRefresh happening before the POST these events and almost the components are now useless and it breaks any previous implementations of these events.

There is a work around for the moment that works to a point. The only place I've found that it doesn't work is if there is a dataView on the destination page and the dataView's configuration is programmatically determined (works fine if the configuration values are static). The work around is to add a callback to the RPC call with a partialRefresh of the destination page's first child element. Don't even try and use the events defined on the appPage component. So, if you watch the network traffic you'll see a GET then a POST and then another GET. This does however introduce a pretty good performance hit.

I think it's great that IBM listened to the community and added these events. However, it seems pretty obvious that the community wasn't given the chance to find these issues before the release. I think it also shows that these events weren't tested properly in a real world scenario. I guess if the events were called onBeforeBeforeTransitionIn/Out and onBeforeAfterTransitionIn/Out it would've made a little more sense.

Just posted over on SocialBizUg a tutorial for putting together a responsive layout for your XPage Applications.

On SocialBiz User Group - The Modern Notes Developer

Check out my first NotesIn9 video about adding a Dojo Scrollable Pane in order to get a fixed bottom tab bar with the Extension Library Mobile Controls. A big thanks to David Leedy for publishing my video. Hope you enjoy the video.

I've published an article over on SocialBizUG describing how to take over an IBM Renderer to include your own style classes. Check it out, hopefully you'll find some use for it.

At Red Pill Development, Peter Presnell has encouraged our development efforts to use a "Mobile First" approach. The process is that you design your mobile interface first, get everything working properly and then move on from there to Tablet and then Web Browser interfaces re-using as much as possible from the previously working mobile implementation. This approach has several advantages:

  • It forces you to research, gather requirements and only display and write code for the things you actually NEED
  • The flow of the application will be defined by the mobile interface
  • It shapes the direction of the entire project
  • It forces you into thinking differently
  • Makes the next interface implementations easier

At first I fought this approach as it was easier for me to come up with a browser based solution quickly. But as we're progressing down this road, I'm finding that by doing Mobile First all of the hard stuff is already done by the time you get to the next implementation. You don't have to figure out where data is coming from, how it's being represented and how to handle the little issues that always seem to pop up. They've already been addressed in the Mobile site so they're usually already taken care of.

Another advantage of the Mobile First approach is that it buys time to experiment with different techniques and technologies. I say this because of how quickly a mobile interface can come together using the mobile components in the extension library. Are there shortcomings with these components? Sure there are, but they perform very well. These components can be extended and improved by taking advantage of the properties, methods and events from their original dojox widgets.

Now I know you're thinking... what about responsive design? Well, you're right to ask about that. Responsive design certainly has it's place and is very powerful and easy to implement. However if you start off with this approach you'll find yourself putting things in that you don't really NEED. You'll be designing for the browser and not the mobile device. Plus, it's certainly argumentative as to if it works well on a mobile device. Sure there are some sites that got it right, but there are some that don't. The counter argument would be that if you're intent on doing a responsive design that you start off designing for mobile first. This forces you to only include things on the screen that are needed.

While I know I've argued with myself here some, I hope I've made a point or at least put an idea in your head to at least try it on one project and see where it leads you. I bet you'll be pleased with the outcome.