Mapping the Tools in the Mobile Development Ecosystem – And How Tiggzi Mobile App Builder Fits In

ReadWriteMobile has posted an interesting Infographic created by Kinvey mapping the current mobile ecosystem (click on image to view larger version):

(Image source: http://kinvey.com/images/kinvey_backend-as-a-service_mobileecosystem_2100px.png)

First of all thanks to Kinvey for creating this wonderful map and including Tiggzi in it (blue Mobile SDK line). Tiggzi could actually span 3 different lines: BaaS, Mobile SDK and Mobile API. Tiggzi is a cloud-based HTML5 mobile app builder, so it’s not exactly a mobile SDK. In fact, the technology under the hood is HTML, JavaScript and jQuery Mobile. For hybrid apps, the app can be wrapped in PhoneGap, which also provides access to native device features. So, there is no really “custom” SDK.

Second, from the builder it’s incredibly easy to consume any REST API (yellow Mobile API line). Tiggzi comes with a pretty nice REST services console where any service can be tested. From the same console, the REST service response (structure) can be automatically created. Once the service is defined, it is mapped to jQuery Mobile UI using a visual mapper (UI to service input, service output to UI).

Thirdly, as most BaaS services (orange line) are exposed as REST, HTML5 mobile app built in Tiggzi, can easily connect and use those services.

Lastly, and maybe the most important point is how incredibly fast you can build apps. It sort of all makes sense.. you got cloud-based mobile backend (exposed as REST) and cloud-based app builder to build the apps. It sounds simple.. but a really elegant picture.

This perfectly describes Tiggzi. Tiggzi is cloud-based builder for creating HTML5, jQuery Mobile, PhoneGap, and RESTful mobile apps.

Webinar: Learn How to Build Mobile Apps in the Cloud with HTML5, jQuery Mobile, REST, and PhoneGap

In this fas­ci­nating hands-on we­binar, a real mo­bile app will be built, con­nected to a REST ser­vice, and tested. Attendees will be be able to test the app as it’s being built. Beyond that, we will also cover some of the ex­citing fea­tures of the new ver­sion of Tiggr that will have been re­leased by then (under a new name…).

Learn How to Build Mobile Apps in the Cloud with HTML5, jQuery Mobile, REST, and PhoneGap
January 19, Thursday
11am US Pacific Time
Register: https://www1.gotomeeting.com/register/486123896

Pretty Darn Good Tools – Building a Mobile App With Tiggr and Parse

I’m not sure whether there is any other way to describe it but building a mobile app in Tiggr Mobile Apps Builder and connecting to Parse mobile back end is super easy and fast!

Here is how the app look in design time in Tiggr:

There are three REST services on the right which connect to Parse mobile back end. The services are for loading the current list items, creating new list item and deleting a list item. For example, this is how the service URL to get all List items looks:


https://{username}:{password}@api.parse.com/1/classes/List

List – is a class I created in Parse.

This is how the service URL looks for deleting an item:


https://{username}:{password}@api.parse.com/1/classes/List/{objectId}

objectId – is the class Id to delete.

Parse mobile back end is very easy to use and is very elegant.

Here is how the actual app look when running:

I’ll publishing the actual tutorial on how to build this app.

It’s almost funny how fast a mobile app can be build using Tiggr and Parse. The app was built in about 30 minutes, with nothing to download or install, all the tools are in the cloud.

Happy New Year!

Visual Mapper: jQuery Mobile to REST Services

Mapping mobile UI to service is one of the most basic tasks in any mobile app (or a standard Web application). Input data entered by the user is sent to the service (input), the service is invoked, returns data (result) is sent back to the app for displaying results. Tiggr Mobile Apps Builder makes it super easy to map UI to service. Let’s look at an example.

REST service settings:

REST service input parameters:

REST service output parameters:

To open the standard mapping editor, there are two buttons in properties for a service:

Mapping UI to service look like this:

The service input parameters are on the left and are mapped to input components and properties on the right.

Mapping service back to UI for displaying the result looks like this:

The service output parameters are on the left and are mapped to output components and properties on the right.

Now there is even a more visual way to do the same. There is a new Data Mapping tab in the main editor, clicking the tab will open a visual data mapping editor:

That’s a pretty cool way to do mobile UI to REST service mapping.

Building Mobile Apps Using Cloud Services [Slides]

Slides from my talk at AppsWorld conference in London (Nov 29-30) on building mobile apps in the cloud with Tiggr.

TRULY Rapid (Mobile Apps) Prototyping with StackMob and Tiggr

The post originally appeared on StackMob blog: http://www.stackmob.com/2011/11/truly-rapid-prototyping-with-stackmob-and-tiggr/

The blog post is written by Crawford Comeaux an independent mobile app developer that recently participated in Startup Weekend down in Baton Rouge, LA and ended up winning. This post is about how he used StackMob and Tiggr to quickly build a web app prototype during the Startup Weekend event. His app is called AudienceAmp and he needs your help to win Global Startup Battle. Please vote here if you like his idea. Here is his story.

I love Startup Weekends! They provide me a chance to easily find like-minded people looking to make their ideas a reality and they’re nothing but fun. Grueling, exciting, stressful fun. On any given weekend, there’s likely at least one going on somewhere in the world. I’ve been to four of them, successfully pitched one of two ideas at each and my teams have placed three times. These things are like crack for wannabe entrepreneurs with ADHD…or at least for THIS wannabe entrepreneur with ADHD! If you are not familiar with the program, you can find out more here.

I participated in my fourth Startup Weekend from November 11-13 in Baton Rouge, LA. I went in determined to win, since winners of Startup Weekends going down on that weekend & the next were eligible to enter into the Global Startup Battle. The winner of the battle is chosen via online voting and there can only be one. The prize up for grabs has the potential to launch the winning startup. So yeah…I wanted that chance, but first I had to win locally.

Most people go into Startup Weekends with just an idea. There’s no preparation done ahead of time. Me, I’m not going into battle without a plan. I wanted to be able to focus primarily on the prototype for the weekend, since the rest of the work had been pretty much addressed at SW Dallas a few months earlier. We built a prototype in Dallas, but the concept for the app had expanded a bit since then and I wanted to start from scratch. I couldn’t count on developers being available, so that meant it’d likely just be myself and a buddy of mine who’s recently developed an interest in interface design. Since the product is a set of mobile apps and we wanted to present with a live demo that others could participate in, that meant it had to be a mobile web app. And we had 54 hours…so we needed development platforms that 1) a non-coder could use 2) produced mobile web apps 2) allowed for “rapid prototyping” (slamming out quick, successive versions of a product)

There are different platforms/libraries/toolkits/etc that are recommended for “rapid prototyping,” but almost all of them define “rapid” from a non-Startup-Weekender-with-short-a-attention-span perspective. Most of the options available have a bit of a learning curve before you can quickly do whatever you want to do, especially if you’re not a coder. And even with simple docs, coding introduces potential fat-finger syndrome. I’m sorry, but a platform that allows for typo-generated errors or bugs doesn’t fit my definition of “rapid.” There are tools for preventing issues or at least detecting their origins, but the tools aren’t perfect and I want to minimize the amount of time I have to spend fixing glitches.

Thus, I went on the hunt for robust, but ridiculously simple solutions. I knew about PhoneGap Build, but wanted to see if there was something beyond that for building the frontend. What I found was Tiggr, a web-based app builder that supports mobile web app development via jQuery Mobile and has a simple drag-and-drop interface builder that let me set properties/events. Not only can projects be exported to your choice of HTML5/CSS/javascript or native Android/iOS projects, but it’s also collaborative!

Front end platform? Check! Time to move on to the backend. I’d read about StackMob on TechCrunch recently & knew about Cocoafish after meeting some of their devs at SW San Francisco in May. After doing a little digging, I found a couple more services: Kinvey and Parse. I signed up for beta invites to each & managed to convince all but Kinvey to grant me one (I still haven’t received a confirmation email from them, but they seem VERY new).

When I evaluated the features of each service, I kept an eye out for features that would be useful beyond prototyping. After reviewing the features offered by each, I eventually settled on StackMob for a few reasons. With StackMob, I can set which fields are indexed, as well as which fields in an object are related to fields in other objects. Being able to get expanded object data through relationships will save us the hassle of making multiple calls for a single screen’s data. On top of that, being able to build custom objects was really important. Parse allows for custom objects, that’s it. Cocoafish didn’t support custom objects until a few days ago, so that wouldn’t work for us, either. StackMob was the simplest option.

Building the data model in StackMob took about 15 minutes! Even if you add to that the 5 minutes I spent begging them for a beta invite, that’s still a server-side setup personal best!

I skipped right over the process of setting up a database server and went right into setting up my database tables! Sure, you may have a way to streamline/ease that initial process, but I didn’t even have to bother with it!

There’s one more feature I’d like to mention that StackMob & Tiggr actually share: responsiveness. The day of the presentation, I started connecting the UI to the backend and ran into a snag: I couldn’t figure out how to properly call the StackMob APIs from within Tiggr! I tried several different naive approaches to no end and searched online for the answer. I tweeted at every Twitter account tied to both companies begging for help and got a response within 15-20 minutes…on a Sunday! Jordan, one of StackMob’s engineers, connected with me over Google Talk and logged into my Tiggr account after I gave him access. He’s a backend guy, so he wasn’t able to provide a solution at that point, but I’d already fought the problem for too long & had to move on to preparing the presentation. After I presented, I started getting tweeted at from both sides…apparently people from both companies got together & provided me with a solution!

Long story short: I’m sold on this pairing for prototyping. Their ease of use, extensibility and fantastic customer service make for a pretty powerful combo!

Oh…and in case you were wondering, the app I’m working on is called AudienceAmp & we did manage to win first place in Baton Rouge. I’ve been up for 24 hours tapping into my social connections, writing WAY MORE than I’d prefer and working with an editing team to produce a (hopefully) viral video! If you’d like to know more about AudienceAmp, check out the links below. If you’d like to vote for us in the Global Startup Battle, go here and click the big “Vote” button!

New Mobile Tutorials: Building RSS App, And Hello World with HTML5 Local Storage

Try these new and very easy to follow mobile tutorials: