Blog

Appery.io Mashable coverage:

• New App Bridges Communication Gap Between Devs and Small Biz

Also check out recent Appery.io coverage by TechCrunch and Technorati.

Appery.io was covered by two very popular technology sites:

• Drag-And-Drop Mobile App Builder Appery.io Makes Building Native And Web Apps Easier, Adds SMS and mHealth Plugins (TechCrunch)
• Appery.io: Making Mobile App Building Easy (Technorati)

Check out this really nice blog/tutorial on how to use Appery.io to build a mobile app connected to cloud-based MongoDB, written by Ben Wen from MongoLab.

Cloud Services

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 Appery.io on TechCrunch: Tiggzi’s Drag-And-Drop Mobile App Builder Goes Beyond Templates

Appery.io, 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 Appery.io, the page is running on appery.io 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.

Hosting the page on the same domain

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 (JSON with Padding)

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 appery.io hosted pages. However, it’s up to the service to support JSONP and not all services support this feature.

Cross-origin resource sharing (CORS)

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.

Appery.io proxy

If none of the above options are available, Appery.io Mobile App Builder provides a proxy service that works for testing and apps that are hosted on appery.io. 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.

Google Chrome with security disabled

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

Mobile Web app vs. mobile app

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 Appery.io in it (blue Mobile SDK line). Appery.io could actually span 3 different lines: BaaS, Mobile SDK and Mobile API. Appery.io 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). Appery.io 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 Appery.io, 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 Appery.io. Appery.io is cloud-based builder for creating HTML5, jQuery Mobile, PhoneGap, and RESTful mobile apps.

Originally posted here.

Appery.io – the easiest platform for building mobile apps in the cloud

Appery.io 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 Appery.io 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.

This article You Can Build A Mobile App Today—Yes, We Mean You covers the evolution of build-your-own Web site tools and then shows how the same approach is possible for mobile apps when using cloud-based Appery.io.