Android’s WebView is very primitive in terms of rendering SVG images as the background. I decided to convert them into PNGs and test their rendering. I don’t have photoshop, and I could have used ImageMagick to convert SVGs to PNGs, but whilst googling I found another nifty utility to achieve the same, qlmanage.
In Mac OS X, Quick Look allows one to quickly preview files. qlmanage is a tool used by Quick Look internally to generate the images for the preview.
Please note that it may be limited with how much it can achieve and is not comparable to something like ImageMagick, but still nifty when you don’t have anything else installed on your machine.
Should you venture into developing a hybrid app for Android WebView in versions before 4.4?
NO. Unless you liked fixing bugs for IE6 when you knew that IE8 or IE9 were a bit better and people should just upgrade their browsers. Although, upgrading OS on devices running Android is quite complicated, and should be dealt in a separate post.
With 4.4, the WebView uses Chromium rendering engine, which is most up-to-date and implements the HTML, CSS, and JS specs correctly. Anything before that used a native Android rendering engine which was buggy and didn’t implement the spec properly. Now, the ‘business’ won’t like you distancing yourself from the older versions because as it happens, a lot of users are still running the older version, for example, 4.3, and 4.2.2.
What can you do in such a scenario?
There’s not much you can do, really. Bite the bullet and fix them bugs. With hybrid apps, you can use Android specific stylesheets (in Cordova) to workaround the problems. Android forums aren’t of much help because they simply refuse to backport any bug fixes made in 4.4 (since the whole WebView implementation has been re-written), and your best resource is StackOverflow.
Device (hardware), OS, and screen size for Android can result in endless permutations, and making a choice of supported devices and getting things to look and work consistent across all the possible combination is crazy. It’s like browser wars amplified.
The integration is simple. Documentation is ample.
It just works!
But, do you know how Stripe works out currency conversion charges?
Being a SAAS company means anyone can pay for your service and although you don’t really need to know how the charges work, but it’d be nice if you know how many customers you really need before you make any profit. For you to calculate that number, you need to know how much are you making from one customer every month.
Whilst thinking about it, I came up with a few scenarios. I also made an assumption that in order to attract more customers, you preferred to create your plans in USD:
1. Your Stripe account is set up in GBP. User pays for a plan (in USD) with their local currency which is also USD. How many times does Stripe charge currency conversion fee? Once - to convert the USD’s to GBP’s for you to withdraw, right?
2. Your Stripe account is set up in GBP. User pays for a plan (in USD) with their local currency which not USD (could be any currency). How many times does Stripe charge currency conversion fee now? Twice - to convert the non USD’s to USD’s and then those to GBP’s for you to withdraw, right?
Confusing, isn’t it?
Well, Stripe is very reasonable. It never does what they call a ‘double dip’ when it comes to currency conversion charges. It only charges you currency conversion once when it converts the USD’s (which is what your plans are set up in) to GBP’s (what’s your account in set up as).
How can you save some of money on currency conversion?
Well, if you know where bulk of your customer segment is (I know I said SAAS kind of means you are open for business with anyone in the world), but let’s say for instance you did have that information you can always set up your plans in that currency. The saving won’t be huge, but something is better than nothing, right?
There are a tons of articles out there to help you in writing a plugin. Cordova’s documentation is detailed and very helpful too, but it’s easy for you to get buried under the documentation and go right past the nifty quirks of the framework. Here’s my few tips which may come handy for you when writing a cordova plugin:
If you know a little bit of Objective-C syntax, it will help. It depends upon the kind of plugin you writing. If your plugin is going to dip down in the native iOS world, then Objective-C knowledge is a must. However, I had to do a very trivial thing in the plugin, so I got by fine.
Read and learn from other cordova plugins. There are a ton of plugins and reading their code will definitely help you in creating a successful plugin yourself.
Use Xcode to run your hybrid application. I can see people raising their eyebrows to that statement, but, the latest Xcode has command line tools and cordova leverages them heavily. That means, I could develop the application, run, test it in emulator without ever opening Xcode. But, with plugins, you want to run the application through Xcode to see errors on the native side.
Lastly, plugin.xml is the metadata file, similar to gemspec file in the Ruby world. plugin.xml allows one to write config that ends up getting used by Xcode, so make sure you have the correct interface name that you’d like to access from the javascript side.
Most, if not all, SASS applications need some sort of payment integration to charge customers for subscriptions and repeatedly do it every month (or year or any time interval). if you are looking for one such payment-subscription solution, then Stripe is what you need. Stripe has awesome documentation, amazing dashboard, and the ability to test everything out is icing on the cake. I’ve not had the chance to try any other Stripe like payment integration services and I’m sure they provide similar features. Anyways, today it’s about Stripe, and a lovely little gem called koudoku.
Koudoku is a Rails engine, and gives you all the subscription related stuff that you may ever need. For example: Signing-up with a particular plan, upgrading a plan for a user. It creates customers, charges cards, and updates subscriptions through Stripe’s APIs. You never have to worry about all that. The gem does all that for you. It has customisable views, just like devise, which you can style the way you like. Only one drawback is the support for webhooks is a bit sparse. Only supports three events right now, but the documentation does make that fact very clear.
However, there are a few gotchas:
1. In order to create some testing users, with subscriptions, you need to make sure they are linked to actual customers on the Stripe side, otherwise you will see the following error:
Stripe::InvalidRequestError: No such customer
The best thing to do is create some customers on Stripe in test-mode, and use their id’s when create users with subscriptions.
2. To get the webhooks working, I had to subclass the koudoku webhooks controller, and add the following line of code:
skip_before_filter :verify_authenticity_token
3. Stripe will call your webhooks end-point to notify of the various events on a customer, for example, payment succeeded, charge failed and so on. You can take the appropriate action, for example, to send invoice, or email admin in response to it. I found two very nice resources to test your localhost webhook with Stripe. I presume both use reverse ssh-tunnelling, but they work out of the box, and one is even a rubygem. I used ultrahook, but also found ngrok a little later.
In all, it took me one evening to set-up and test the whole thing end-to-end. It’s so easy that it should be called Stripe-asy!