You can also find me on: google+, twitter, last.fm, github, librarything, granular, steam
@AnuragBhandari twitter updates
Tech enthusiast, open source evangelist, book worm, software developer, sports fan, passionate gamer, movie buff.

Sencha Touch: Accessing a remote API that is under Basic Authentication

ST makes it pretty straightforward to access webservices or APIs through its various data proxies and Ext.Ajax. But consuming an API protected under basic authentication can be tricky. Both data proxies and Ext.Ajax provide setUsername() and setPassword() methods, and they work fine on most browsers. But in my experience using these methods, I had big time face-palm moments in case of Safari, iOS, and some Android versions. When these methods are used, an ST app sets the Authorization header AND makes all API requests through URLs formed such as this:

http://user:passwd@www.server.com/api/user/2627

I’m not sure why this is such a big deal for some browsers, but they seem to get confused due to the presence of these two things — Authorization header and user:passwd URL.

The trick to solving the issue is to NOT use setUsername() and setPassword(), and instead set the HTTP headers yourself.

Data Proxies have a headers config.

someModel.getProxy().setHeaders({
	'Authorization': 'Basic ' + btoa(username + ':' + password)
});

Ext.Ajax has a defaultHeaders config.

Ext.Ajax.setDefaultHeaders({
	'Authorization': 'Basic ' + btoa(username + ':' + password)
});

Mobile App Development: Lessons Learned

  1. Sencha Touch is a great framework, but requires a LOT getting used to. The officials Docs do not always have the answer you’re looking for. ST forums and stackoverflow are excellent resources to consult when in need.
  2. If you are a web developer, DO NOT waste time learning Objective-C or Java for creating native iOS and Android apps. Instead use something like ST to develop a mobile web app, and then convert it into a native app using Cordova / PhoneGap.
  3. Cordova is the renamed, open-source version of PhoneGap.
  4. If your app is data-centeric, most probably it will depend on a webservice / API. If the API and the app are hosted on the same server, no problemo. In case of native apps, that are basically web apps PhoneGapped into native apps, that’d mean calling a remote API, and that is the problem. See same origin policy.
  5. Most googled solutions will point to making the service JSONP supported; but JSONP works only for GET requests. CORS is a recent W3C standard that supports all HTTP methods, but it still doesn’t work for PhoneGapped apps. ASP.NET Web API provides an easy CORS implementation.
  6. The perfect solution is to keep making Ajax calls normally, but using the full URL of the remote API. That will work because a PhoneGapped app doesn’t render in a browser but in a WebView (through a file:// URL). So it’s not restricted by browser’s same origin policy.
  7. ASP.NET MVC 5 and Web API are awesome!
  8. You may frequently encounter annoying cache issues with PhoneGapped apps. Just place a super.clearCache() in your Android app’s main activity’s onCreate().
  9. A PhoneGapped iOS app will run in fullscreen mode, by default, such that the status bar in iOS 7+ will appear over it. A fix is right here!
  10. One can create an IPA archive for testing on iOS devices via Build > *.app > iTunes > ?*.ipa. Believe me, it’s one of the most stupid things you will ever do. This is the correct way to create IPA archives for ad hoc distribution.
  11. Here’s how to create an animated splash screen in Android (though I have yet to figure out how to correctly use this in a ST-PhoneGapped app).
  12. If your device has Android 4.4+, you can remote debug your WebView-based Android apps using Chrome.
  13. JavaScript is yummy!

Sencha Touch: Third-party plugins and build errors

Nothing beats Sencha Touch when it comes to sheer number of options and versatility in developing for the mobile. ST has truly set the benchmark of mobile development done right with each major release. It has a vibrant user community, and a robust enterprise adoption. But, sadly, although the documentation is good, it sometimes feels a bit incomplete. If it weren’t for stackoverflow and ST’s official forums, it would have been difficult for me to complete some aspects of my recent mobile app project. Coming to the point…

ST recently announced the much awaited grid feature . They call it Touch Grid. On the surface, it looks super-customizable (just like everything else ST) and enterprise-ready. In short, it’s just what everyone was waiting for. Unfortunately, it is not available for free. Touch Grid comes as part of the Sencha Touch Bundle, something only suited to the enterprise due to its staggering $695 cost.

A couple of months ago, I was looking for something like Touch Grid for my app. The exorbitant pricing of ST Bundle compelled me to look for free alternatives. That was when I found Ext.ux.touch.grid. Its last release was well over a year ago now, and was tested with ST 2.2. But it still works with ST 2.3 (the current release). Including its source folder “Ext.ux.touch.grid” in the root of my ST app and adding a reference to it in my app.js was all that was needed to get it to work.

When I built my app for production deployment (sencha app build production), I got this error:

Unknown definition for dependency: Ext.ux.touch.grid

The above error basically pops up because of not adding a dependency (say, a plugin) in your ST app’s classpath. Adding it to the classpath resulted in the yet another error:

com.sencha.exceptions.ExBuild: java.lang.IllegalArgumentException

A small tweak fixed this error: I created a new folder “plugins” in the root of my app and moved the “Ext.ux.touch.grid” folder into it. I edited my app.js to change the plugin’s path, and likewise changed the classpath.

Add this to the top of app.js (before Ext.application declaration):

Ext.Loader.setConfig({
    enabled: true,
    paths: {
        'Ext.ux.touch.grid': './plugins/Ext.ux.touch.grid'
    }
});

And add the “plugins” folder to the app’s classpath (edit .sencha/app/sencha.cfg):

app.classpath=${app.dir}/app.js,${app.dir}/app,${app.dir}/plugins

Now build again, and all should be fine!
Happy coding.

MonoDevelop 4: CSS files not loading for an ASP.NET MVC4 site

MonoDevelop 4

MonoDevelop 4

If you are like me — always living in Linux, but sometimes being required to develop ASP.NET sites — you have no doubt used MonoDevelop. While its latest iteration brings in many good things, it’s still not the ready-to-use Visual Studio.

Once you are past the System.UnauthorizedAccessException and Could not load file or assembly ‘System.Web.WebPages’ errors, you might encounter another weirdo in an imported MVC4 site, an error that prevents loading of default stylesheet(s) in browser. As a result, your site may look completely deprived of any styles, colors, images, etc.

The origin of this error lies in the simple fact that while Windows (possibly the source of your imported MVC site) is case-insensitive with file names, Linux isn’t. Correcting this is as simple as:

  1. opening the file App_Start > BundleConfig.cs, and
  2. changing
  3. bundles.Add(new StyleBundle("~/Content/css").Include("~/Content/site.css"));

    to

    bundles.Add(new StyleBundle("~/Content/css").Include("~/Content/Site.css"));

  4. that is: site.css to Site.css

Merry coding!

My dear ol’ Google Nexus

I’m pretty happy with my Nexus 7. So far, no major complaints. Typing is a breeze. Gaming is fun. Reading books is very convenient. Watching movies is a pleasurable experience. Plus it’s running the latest Android–Kit Kat. For its accessories, I bought an OTG cable and a music case cum carry pouch.

I’m enjoying every bit of this cute little, cheap and quality device. ☺

Posted from my Nexus 7

Loading...
X