Testing AirPrint from your iOS apps

Recently while working on our iOS app we had to integrate AirPrint feature in the app to let the user print some documents from the app. AirPrint is an Apple technology that lets you print documents from your iOS and MAC devices without requiring any additional software. The printer needs to be AirPrint capable and many latest printers have adopted the technology. A full list can be found here http://support.apple.com/kb/ht4356.

But if you are stuck with a printer which is not AirPrint compatible (check your printer model in the link above to see if it is indeed AirPrint compatible or not), you can still test your app with that printer. Thanks to my teammate for pointing me to this useful software called handyPrint which helps you with exactly this issue.

For testing from an iOS simulator:

1. Your MAC machine needs to be on the same network as your printers.

2. So, before handyPrint, if you go to your iOS app on the simulator and try to search for a printer, it will show you the below message. Even though printers are available on your network, they are not AirPrint compatible.

Screen Shot 2014-05-06 at 3.54.40 PM Screen Shot 2014-05-06 at 3.54.50 PM

3. Download and install handyPrint from http://www.netputing.com/applications/handyprint-v5/

Screen Shot 2014-05-06 at 3.56.13 PM

4. Open handyPrint. It will show you your network printers. Turn the switch it displays to ON. You will see a green light below with the text ‘Sharing’.

Screen Shot 2014-05-06 at 3.56.54 PM

You will notice that this is a trial version of handyPrint valid for just 14 days. You can purchase the full license with a very small donation (as less as 5$).

5. Now go back to your app on the simulator and click on Search Printers. This time it will show up both the printers that are being displayed on handyPrint. Select any printer you like and give a print command and it will all work.

Screen Shot 2014-05-06 at 3.57.13 PM

For testing from an iOS device:

1. Make sure handyPrint is installed and your printers are shared as detailed above.

2. On your MAC, click on the wifi option and click on ‘Create Network’.

Screen Shot 2014-05-06 at 3.59.16 PM

3. Enter a name for the network and click create.

Screen Shot 2014-05-06 at 3.59.30 PM

4. Your MAC will now broadcast the TestPrinting network. On your iOS device, go to Settings->Wifi. You will see ‘TestPrinting’ listed or you can add it from ‘Other’ option. Your iOS device will now be on the TestPrinting network. Connect your MAC to an ethernet cable to make sure that the connection between the MAC and the printer still works.

photo 1 photo 2

5. Go to your app on your iOS device and search for printers. The two shared printers will now show up. Select a printer and give the print command and it should work. You can see the job in the print queue on your MAC as well.

photo 3 Screen Shot 2014-05-06 at 4.10.21 PM

Advertisements

iOS 7 app icon sizes and misc. information

I wanted to create a one-stop guide for the icon sizes that are required for any app submitted to the app store and one that is compiled with base sdk iOS 7.x and targeting iPhones and iPad devices. The below table is an exercise for exactly that. Also included is some miscellaneous information that may come in handy.

iOS7_icon_img_size_name

The ‘Image name’ row is just a file naming convention for the resources that you use for a particular device type.

Although iPhone 5, iPad 3rd and 4th gen are no longer being sold by Apple, I decided to keep them in the table since they use the same set of icons as iPhone 5C/5S and iPad Air respectively (which are being sold by Apple as of this day).

For more information, you can refer to Apple’s own documentation:

https://developer.apple.com/library/ios/documentation/userexperience/conceptual/MobileHIG/IconMatrix.html

3D dragging in iOS using Core Animation

I recently installed an app on my iPhone called ‘Taasky’

https://itunes.apple.com/us/app/taasky-beautiful-simple-easy/id720309412?mt=8

It is a simple task manager to create and manage your to-do lists. Despite the simple functionality it is ordained to do, the UI is beautiful and intuitive and the animations are elegant. One particular animation from the app struck a chord with me. It was a 3D dragging of a view from the top when you pull down your main view to create a task. I have recently started learning Core Animation programming in iOS and wanted to emulate this particular animation of Taasky as best as I can.

The result is my HV3DDrag project on github: https://github.com/hetalv985/HV3DDrag

And here is a video of the animation in action that the HV3DDrag project achieves:

 

Please checkout the project on github and do let me know through your comments if you have any feedback.

Git and Github

Git is a distributed version control system and it differs from a centralized version control system like SVN in quite a few respects.

SVN involves a central repository. Each client then checks out a copy of this repository to make a local copy called the ‘Working directory’. Each client makes changes to his own working directory. The changes are committed to the Central repository when the client checks in i.e.commits the code.The central repository maintains the older versions of the code as well. Hence the client can rollback his working directory to a previous version of code from the central repository.

Git (–distributed is the new centralized) also includes a central repository. But in addition to the central repository, each client has his own repository on his local machine. Essentially, the working directory in this case acts as a repository in itself. Commits, rollbacks etc are to be done first at the working directory level and then pushed to the remote branch in the central repository. The client here can rollback to a previous version of code from his local repository or from the central repository.

For more details on the differences between Git and SVN, here is a good link

http://boxysystems.com/index.php/5-fundamental-differences-between-git-svn/

When you are moving away from SVN and towards Git, things can be confusing. I published a couple of projects on Github and that is how I got my first taste of Git.

This blog simply aims at giving you the basic Git commands that you need to know in order to work with Git and publish your projects to Github. The commands and responses below are all from MAC OS X 10.8.5 Terminal app.

To demo this, I am going to create a Test iOS project and publish it to Github.

1. Create an account at github.com.

2. Create your project on your MAC that you wish to publish to github. In my case, I am creating a Test iOS application project. Xcode provides you a capability to create a git repository as you create the project, but I will create it using a terminal command.

3. Check if you have git on your MAC. The latest versions of MAC OS X come with built in Git. You can check for this from the Terminal using the command

$ git –version

If you do not have git installed on your desktop, download and install it from http://git-scm.com/downloads

Once git is installed, navigate to your project folder path in the Terminal and use the below command to create your local git repository:

$ git init

4. You can see that the above command adds a .git hidden folder in your project folder. To see the .git folder, navigate to your project folder in Finder, click on the ‘Go’ option on the top menu and select ‘Go to Folder’. Type in ‘.git’ and click Go. This will show you the hidden .git folder and the contents under it.

.git folder

5. On github, login with your account and go to Repositories tab. Click on ‘New’ to create a new repository. Provide the repository name. In this case, I am going to name it as ‘Test’. Provide a description (although it is optional, its good to provide one). Select the option ‘Private’ or ‘Public’ to indicate who can see the repository. ‘Private’ option will need you to have a paid account with github.

At this point you can add the README file and license by selecting the checkbox ‘Initialize this repository with a README’ and selecting appropriate options in the dropdowns below. You can add these files later as well.

Creating new repository on github

Click on Create Repository. At this point, this is an empty repository on github.

Github Test repository

You will now need to add your project to this repository.

6. In order to add your project to the github repository, you will first need to add the files and folders of the project and commit them locally. In order to do this, type the following commands in the terminal:

In order to selectively add the files to commit, type the following command:

git add <files or folder name>

Alternately, in order to add all the files in the current folder and its subfolders, type the command as

git add .

7. Once the files to commit have been added, you need to do a local commit first using the command

git commit -m “message”

“message” should be any commit message that you wish to provide.

add and commit files

8. Configure your git username, email address and password as below

git config –global user.name “your name to be visible when you commit”

git config –global user.email “your email associated with github”

git config –global user.password “your github password”

9. You will then need to add your github ‘Test’ repository as your remote origin using the command:

git remote add origin <git repository url>

10. Your remote repository is called has the origin branch by default. To push your local repository a.k.a. master to the remote github repository, use the command:

git push origin master

push to origin

If you now check your repository on github, you will see your project files added in it.

Github Test repository

11. To update your local copy with the changes from the remote repository, use the command

git pull <git repo url> <branch name>

If you do not wish to work with the command line tools, there are GUI clients available for git. Take a look at

http://git-scm.com/downloads/gui

These are the basic steps to using git and publishing to github. There is a lot more to git than this. This should hopefully help you get started. Do leave your comments if you found this useful.

Same-Origin policy and working around it

Scripting languages like Javascript are restricted on their ability to call a service hosted on a domain different than their own domain by a policy implemented in the browsers called the same-origin policy.

The domain is determined by 3 parameters of the url:

– protocol

– host

– port number

If any of this differs between the caller domain and the callee domain, the javascript call to the callee domain will return an error saying cross domain requests are not allowed.

More information: http://en.wikipedia.org/wiki/Same_origin_policy

To overcome this constraint, at least 3 solutions exist today:

JSONP – JSON with Padding

This is an older technique supported by all the browsers. This works if you are calling a service which returns a JSON response. You make the service call as the ‘src’ attribute value of a <script> tag and pass the name of the callback function in the url. The service will then respond back with a javascript call to the callback function and the JSON response will be passed as the parameter to that function. You implement the callback function in your javascript code and this is where you will receive your response.

The deal with JSONP is that it is not secure since any javascript can be injected in this way by the server. Also, this approach works only for HTTP GET requests.

CORS – Cross Origin Resource Sharing

This was introduced to provide a more secure solution than JSONP and now CORS is supported by all latest browsers. CORS involves addition of some new HTTP headers in the response from the server. The browser on receiving these headers will determine if the javascript call is allowed or not. Primary amongst these headers is

Access-Control-Allow-Origin: *

A value like ‘*’ will allow requests from any domain to call this service. A more restricted value can be applied to limit successful requests from specific domains only.

Apart from this, there are a number of other headers that may/may not be needed for CORS to work depending on your call. Some of them are as below:

Access-Control-Allow-Methods: <comma separated list of methods that the server allows>

Access-Control-Allow-Headers: <comma separated list of headers allowed by the server in the client request>

Apart from this, the server should also support a call to HTTP OPTIONS method which the client calls during a preflight request. The preflight request is made prior to making the actual HTTP request to the desired method and is used to determine the allowed HTTP methods that the server supports and also the allowed origins. When the OPTIONS request returns a successful response, the browser automatically will make the actual HTTP call for the desired method.

Here is a good reference on CORS:

http://www.w3.org/TR/cors/

Reverse Proxy

This is when you create a proxy between your javascript and the service such that the proxy is hosted in the same domain as the javascript. The javascript call to the service is then modified to be a call to the proxy and since the proxy is in the same domain as the javascript, it does not throw a cross domain error. The proxy will be responsible for calling the actual service on another domain, getting the response and then passing back the response to the javascript. The proxy can be a simple servlet or even a server like Apache or IIS can be configured to act as a pass through proxy.

Here is how you can configure the Apache server on a MAC (we are going to use the Apache server which comes installed by default on the latest MAC OS X versions) to act as a passthrough proxy:

Go to Terminal and type in

$ sudo nano /etc/apache2/httpd.conf

In the httpd.conf file, add the 3 lines highlighted below:

Listen 80

ProxyRequests off

ProxyPassMatch /<keyword>/(.*) <destination service domain>/$1

SSLProxyEngine On

Hit Ctrl+O to write out your changes to the conf file. Hit Enter. Hit Ctrl+X to exit.

Restart your apache server from the Terminal:

 $ sudo apachectl -k restart

The important line here is

ProxyPassMatch /<keyword>/(.*) <destination service url>/$1

This essentially means that when you make a call to this local Apache server in your javascript code with a url like

http://localhost:80/<…>/<keyword>/<rest_of_the_path&gt;

the server will act as a proxy and make a call to

<destination service url>/<rest_of_the_path>

and return back the response from the service call to the javascript.

Using this ProxyPassMatch, we are limiting the Apache server to only act as a proxy for the url calls that have the pattern ‘/<keyword>/’ and to append anything after ‘/<keyword>/’ to the destination url.

For more details on creating a reverse proxy, please refer:

http://overwatering.org/blog/2012/04/reverse-proxy-javascript-app/

In addition, I still haven’t found a reasonable explanation as to why the same-origin policy won’t affect a native app running javascript in a javascript engine or a hybrid app running it in a web view:

http://stackoverflow.com/questions/21143963/why-doesnt-same-domain-policy-affect-native-mobile-apps

If you have a good explanation, please do post it in the comments.

HTML5 – Clocks

My another Github project that I published during my learning phase of HTML5 (I am still learning) was a simple clock demo. It displays an analog and a digital clock. Works great on mobile web browsers as well. It uses the HTML5 canvas element and javascript apis to render.

Here is the link to the Github project: https://github.com/hetalv985/Clocks

The project is available for free under the MIT license.

Feel free to leave your feedback and suggestions.

iOS – Color Selector

I recently published a simple color selector tool for iOS. The project is available for free under the MIT license and can be integrated easily in your iOS apps. It is currently designed to work for iPhone 4, iPhone 4s, iPhone 5 and iPhone 5s form factors. The project has been created with Xcode 5.0 with Base SDK iOS 7. The deployment target is iOS 6.0 which means it works on iOS 6.0, 6.1, 7.0 and above. The code has been tested on iOS simulators for iOS 6.0, 6.1 and 7.0 with 3.5 inch and 4 inch displays.

Here is the link to the Github project: https://github.com/hetalv985/HVColorSelector

And here is a link to the wiki page where you can see the screenshots:

https://github.com/hetalv985/HVColorSelector/wiki

If you have any suggestions or feedback, please feel free to leave a comment.

Note: In case you face a crash when trying to run the project, select the Target in Xcode. Click on General. Go to Deployment Info section and set the ‘Main Interface’ to be either ‘Main_iPhone4’ or ‘Main_iPhone5’ storyboard and then run the app.