Check out this really nice blog/tutorial on how to use Tiggzi to build a mobile app connected to cloud-based MongoDB, written by Ben Wen from MongoLab.
In the past year or so, we have witnessed a major shift from client-server to client-cloud. This shift is primarily fueled by two factors: mobile devices exceeding desktop computers and the thousands of different APIs available on the Internet today. What started in early 2000 on eBay and Amazon has become a real revolution in 2012 with thousands of companies, from Twitter and Facebook to AT&T, offering cloud-based services.
REST API
One of the most common ways to access private or public service APIs is via REST requests.
In the client-server approach an organization builds applications that consume its own internal content and resources. However, even large IT organizations such as AT&T, Verizon and Amazon have come to realize that they are no match for the social consumer and social enterprise developers out there. By making APIs publicly available, these organizations hope that developers and “citizen developers” will come and build applications and mobile apps on top of their services.
Citizen developers at work
Analysts at Gartner see a trend toward app creation independent of IT. They predict that by 2014, citizen developers – employees outside of IT and software development – will build 25% of new business applications. In 2007, they built less than 5%.
One of the best-known API success stories comes from Amazon: Its cloud service APIs let outsiders access the company’s massive data centers. Twitter, with its deceptively simple 140-character message model, exploded thanks to its API. In fact, you probably read and write tweets via a Twitter application or mobile app rather than going directly to Twitter’s Web site. Facebook’s Graph API has spawned a whole industry of apps to support its hundreds of millions of users.
Continue reading
A write up about Tiggzi on TechCrunch: Tiggzi’s Drag-And-Drop Mobile App Builder Goes Beyond Templates
You can extend the functionality of any Tiggzi component by adding custom JavaScript. Today, we’ll see how the Google Map component in Tiggzi can be used to display driving directions both visually and as text.
With the help of the Google Directions service, we’ll create a mobile page similar to the directions example listed on the examples page for the Google Maps API. Read the rest of this entry »
Do you know how to take advantage of custom JavaScript when working with Tiggzi visual components? You can easily access any Tiggzi component in JavaScript via the Tiggzi JavaScript API and manipulate it with the jQuery Mobile API. Here is an example of how to dynamically add items to a list using JavaScript. Read the rest of this entry »
Tiggzi, the cloud-based HTML5, jQuery Mobile and PhoneGap mobile app builder come with a very powerful and easy way to define and consume REST services in a mobile app. Inside the builder, you get what amounts to a very easy to use REST services console where any service can be defined, tested, and have its response parameters automatically defined.
Being able to run and test the service from inside the builder is very important as it demonstrates that the service works and data is returned. The next step is usually to make the service available on the page, define UI-service data binding, and then set the service to be invoked on some event. But, when testing the app in a browser, the services sometimes doesn’t work or no data is returned. This creates confusion as the service worked when testing it inside the builder but doesn’t work when invoking from a browser page. The reason this happens is because of the cross-domain security built into browsers.
All browsers have this built into them. Basically, to invoke a service via JavaScript (AJAX) from a domain like mydomain.com, the page from which the service is invoked has to be hosted on that same domain, mydomain.com. When testing an app built in Tiggzi, the page is running on tiggzi.com but the service being invoked is on a different domain like, for instance, search.twitter.com. The browser won’t allow this. This is by design to ensure that no bad or malicious JavaScript code can be used to invoke the service.
What can we do? There are a number of options to make this work.
The most obvious option is to host the page and the service on the same domain. The solution is simple but not very practical today. With the new shift to a client-cloud architecture, many services used in mobile apps today are cloud-based, and are hosted via different API providers and thus are on different domains. Hosting the page and the service on the same domain might work well if services were deployed completely within the same organization.
JSONP is the unofficial way many provides solve the cross-domain problem. Instead of making a regular AJAX request which is subject to cross-domain security, the request is made via loading a JavaScript file with a special callback function defined. As loading a JavaScript file is not an AJAX call, it doesn’t fall under the cross-domain security problem. The callback function is then invoked to process the data returned (which is JSON). The URL looks like this:
http://someurl?callback=getthedata
getthedata would be invoked to process the response.
With JSONP, a service can be invoked from a page hosted on different domain. For example, Twitter’s API supports JSONP and thus can be invoked from tiggzi.com hosted pages. However, it’s up to the service to support JSONP and not all services support this feature.
While JSONP could be considered a hack or a workaround, CORS is an attempt to create a standard way to solve the cross-domain issue. When a service request is made, the server will include a header parameter in the response indicating that the domain from which the call was made – is allowed to invoke this service. However, it’s up to the service providers to add such support. For example, the Parse mobile back-end service supports this feature and makes it very easy to use their services.
If none of the above options are available, Tiggzi Mobile App Builder provides a proxy service that works for testing and apps that are hosted on tiggzi.net. When using the proxy, the request is first sent to the proxy server and then, from the server, the request is made to the service. Because the request is sent from the server and not from the page, cross-domain security is not triggered.
Finally, one more option exists, but it’s only useful in development or testing. You can start Google Chrome with security disabled in which case the cross-domain issue is no longer a problem. To start Chrome with security disabled start it with this command line:
chrome –disable-web-security
Everything I just described applies to mobile Web apps - pure Web apps running in the browser. When you develop a PhoneGap app (hybrid app) cross-domain security is not an issue, even though the app is actually running in a browser (albeit a chromeless one).
Next time you are trying a REST service, this should help you understand that’s really happening.
Originally published on Maxa blog.
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.
Originally posted: http://mkblog.exadel.com/2012/02/mapping-the-tools-in-the-mobile-development-ecosystem-and-how-tiggzi-mobile-app-builder-fits-in/.
Tiggr is a cloud-based mobile apps builder. It lets developers build HTML5/JavaScript and native apps very quickly, entirely in the cloud. There is nothing to download, nothing to install, and nothing to configure. Just create a new project, and you are ready to start building your mobile app with HTML5/JavaScript and PhoneGap.
Continue reading Building Mobile Apps in the Cloud with Tiggr and PhoneGap
This article was written by Crawford Comeaux and published on StackMob blog. Crawford is 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.
Here is his story: TRULY Rapid Prototyping with StackMob and Tiggr.
Ask anyone involved in making applications as a developer or a customer: Would you like to see how the app looks and behaves before we actually build it? The answer is an overwhelming yes. We humans are very visual. For us, to understand something better, we would rather look at a prototype than just read a description. That’s exactly why prototyping is hugely important today.
Even though prototyping is crucial to any project, a real prototype is rarely fully developed. Why? There are a number of reasons. First, lack of the right tools. Second, most of the tools that do exist today just enable you to create a static mockup. And third, some believe it’s a waste of time, as the real app usually looks very different from the prototype, so why even bother with it. These are all valid concerns, but a new prototyping tool solves these problems. This prototyping tool is Tiggr Mobile Apps Builder.
Tiggr is cloud-based service for building mobile apps. It enables you to quickly and easily build real mobile Web and native apps, entirely in the cloud. Mobile prototyping and prototype testing is a major part in this cloud-based service.
Continue reading: http://uxmovement.com/resources/innovative-features-in-tiggr-mobile-apps-builder/