Codiqa is the fastest mobile prototyping tool around. Learn more

codiqa-ios-header

Hey there!

In our last post, we went over how to use Codiqa for packaging native Android apps. We hope it was helpful, and that you were able to make some stellar Android apps. Today, we will be covering the basics of how to export for iOS from Codiqa! Let’s dive in…

The iOS export has two build modes similar to the Android export, however unlike with Android, you need an Apple Developer account before you can test on your device, to include using Codiqa Export.  Unfortunately, the Apple Developer account costs $99 USD.

So what kind of builds can you export with Codiqa? The two build modes are a Development Mode for testing on your devices, and a Distribution Mode for uploading the app to the Apple App Store.

build-development-mode
For both these processes you need two files, which are relatively easy to obtain.

What You Need:

  • Mobile Provisioning Profile (.mobileprovision)
  • Certificate File (.p12)
    • Certificate Password

Once you’ve setup your Apple Developer account with XCode on Mac OS X these files should already be in place. Easy!

The Mobile Provisioning Profile file ends in .mobileprovision can usually be found in:

/Users/<your username>/Library/MobileDevice/Provisioning Profiles/

Make sure the profile you upload is linked to the device or devices you wish to test on.  Also, for Development Mode you can make a wildcard provisioning profile for all your apps as a developer (which is usually the default, so don’t even listen to me).  For Distribution Mode you must upload a provisioning profile with your specified package name under more options.

The Certificate file needs to be exported from the Mac OS X Keychain Access utility, as seen below.  Right click or Ctrl click on the Certificate -> Export

keychain-access-codiqa

To export the Certificate you need to password protect it.  This is the password needed for the Codiqa Export, the build will fail without it.  But no worries, you can remember a password for 30 seconds, right?

password-alert

Note: All of what you need can also be done without a Mac by generating the Certificate and the Provisioning Profile through the Apple Developer site. However, that is outside the scope of this blog.

You should get an email shortly after you submit the Codiqa export, which you can open and download the .ipa file.  The .ipa file is your app which can then be synced to your iOS device via iTunes.  Now you can have fun showing off your mad app building skills to your friends and most importantly not even break a sweat!

If you do find something not working, don’t fret! Make sure you have correctly entered your passwords and are uploading the correct files. If you are 100% sure everything is correct and things are still giving you trouble, feel free to send us an email at support@codiqa.com.

And that’s it! As always, let us know how it goes and what you think of the service. We like hearing your feedback and suggestions, because it helps us improve the product. Happy building! 🙂

Peter Collins

Happy Developer. I like taking names and coding backend systems in Go for Codiqa. Say hello to me on Twitter!

More Posts

codiqa android build

Hey friends!

Have you ever wanted to know how to build a native app from Codiqa so that you can test directly on your device or even put it in the Google Play Store? It’s easy just follow me!

Codiqa currently supports exporting and building to two platforms: Android and iOS, which can be accessed from either your project dashboard or the project build editor itself.  This post will focus only on how to build to Android. We will cover iOS in the next one!

ways to export

From here you see the export menu with several export format options and an email to send the export to.

standard export window

Currently supported are an HTML zip export of your project code and assets with several options, a Phonegap/Cordova Project zip export for both Android and iOS, and, finally what this blog will cover, a Build Mode for Android. Let’s get started…

Debug Mode

This build mode is the easiest! No files are required just submit your build and done! You should get an email shortly after you submit the export, which you can open from your Android phone and download the app .apk file.

export debug mode

As is named this is for debugging purposes only and although a build created this way can be installed on any Android device, it will be unable to submit to the Google Play Store.  To submit an app to the Play Store, you’ll need to export and build using Release Mode for Android which is explained below.

Note: Allow app installs from “Unknown Sources” must be enabled on your Android phone.  This can be found in Settings > Security or Applications > Unknown sources.

Release Mode

So you want to release your Codiqa app the Google Play Store or the Amazon Appstore?  Simple! You just need one file!

What you need

  • Signing Keystore file (.keystore)
    • Alias
    • Keystore Password
    • Key Password (Can be same as Keystore Password)

Let’s generate our signing private keystore using the keytool command that comes with the JDK. If this tool isn’t found, refer to the installation guide as it should be located in %JAVA_HOME%\bin

$ keytool -genkey -v -keystore <keystore file name>.keystore -alias <alias name> -keyalg RSA -keysize 2048 -validity 10000

You’ll first be prompted to create a password for the keystore. Then, answer the rest of the nice tools’s questions and when it’s all done, you should have a file called <keystore file name>.keystore created in the current directory.

Now in the Codiqa export menu, upload your keystore file, enter the alias you specified as well as the keystore password.

export release mode

There are additional options in case you created the keystore using unique passwords for both the keystore and the key.  Also available is the ability to specify a package name instead of the generic com.codiqa.<random id> which will show up as part of the url in the Google Play Store.

Note: Your signing keystore file should be kept private!  That means either store it locally on your development machine or in a private repository.  The same keystore must be used to release an app update on the Google Play Store, so keep it safe! Additionally, all interactions with our export server are over SSL, and we do not store any information.

Refer to the official Android App Signing documentation for more information.

Google Play Store

Now that we have our release APK ready for the Google Play Store, we can create a Play Store listing and upload our APK.

To start, you’ll need to visit the Google Play Store Developer Console and create a new developer account. Unfortunately, this is not free. However, the cost is only $25 compared to Apple’s $99.

Once you have a developer account, you can go ahead and click “+ Add new application” as in the screenshot below:

google play console

Then, you can go ahead and click the button to edit the store listing (We will upload an APK later). You’ll want to fill out the description for the app. Here is a little preview from when we filled out the application with the Codiqa Test app:

google play store listing

When you are ready, upload the APK for the release build and publish the listing. Be patient and soon your hard work should be live in the wild!

That summarizes the Android half of this series. Let us know what your experiences are, we are always interested to hear your opinions. And remember to stay tuned for our iOS edition…

 

Peter Collins

Happy Developer. I like taking names and coding backend systems in Go for Codiqa. Say hello to me on Twitter!

More Posts

codiqa forum

We are excited to announce that the new Codiqa forum is up!  While the previous forum was extremely popular, 16,000 spambots were not really the crowd we wanted to cater to.

Once the inundation of spam began, we realized the original forum had become more of a liability than an asset.  Yet at the same time, we recognized that we have awesome and very vocal users, and wanted to provide a community resource where they could pool their knowledge for the benefit of everyone.

So we have opened up a brand new forum for you, our dedicated users, with the sincere hope that it will become a place you can go to ask and answer questions about Codiqa, share new ideas, and enjoy discussing topics within the mobile space.

You no longer need to sign-up for a separate account – your Codiqa account is now tied directly to your forum profile!  While the forum will be visible to the public, this means that only Codiqa users will be able to comment and post. We built this for you.

You can access the forum at http://codiqa.com/forum/.  We’ll see you there. Happy posting!

Tim Lancina

Fledgling Developer. I love learning new languages and kicking balls with my feet.

More Posts - Website

Follow Me:
Twitter

exported files

Hello!

It’s been longer than we’re comfortable with since we’ve written last, but that doesn’t mean we haven’t been getting lots of exciting things done! Today, I want to show off a brand new exporting experience in Codiqa called, Dynamic Exporting.

When we first started development on Codiqa, we knew that being able to export clean HTML,CSS, and JS files of whatever you build would play a vital role in its success. Our assumption was correct, and in some ways, the code export is at the heart of the product. Without it, Codiqa would have merely been a mockups tool. And after all this time, the exporting function hasn’t really required too many major overhauls or improvements. Quite frankly, it just worked.

Yet, as we’ve continued development on the product, it started to become clear that the exporting could offer even more. Our customers were using Codiqa as a launching point for building a wide variety of apps- be them native iOS/Android, or browser-based web apps. We knew we could make this process easier for them, and today I’m excited to show off the first version! (And I say version 1 because there are many features close behind.)

export window

Here’s how it works:

When you click the export icon in the header bar of Codiqa’s builder page, it will bring up a modal with a few options. The email input, which will be pre-populated with the address you signed up with, is there so we can simply email you a download link which will be helpful when installing and debugging your app on a mobile device.

Next you have different formats you can export your project to:

  • HTML
  • Android
  • iOS: (Coming soon)
  • Windows: (Coming soon)
  • Blackberry: (Coming soon)

The HTML format is what you’re probably used to with Codiqa’s previous export. It packages up all the files into one zip file which can be extracted on your end. Previously, our export feature had external links to your uploaded images, and some external libraries to files like jQuery and jQuery Mobile. The zip file now contains all the files necessary to run your app, without any external links, and places all your uploaded images directly within the package. Note: Most of the time an HTML export will download to your browser immediately, but if there is a large number of images in your app then you’ll have to wait for the email.

Additional features following close behind for the HTML export is the ability to combine all the JavaScript files into one file, and all the CSS files into one file (and if you’re curious why then have a look at the “Best Practices for Speeding Up Your Web Site“). Soon we’ll also add the ability to compress and minify files too!

Another feature we’re excited to show you is our Android build. This means that you can easily export your entire Codiqa project straight to an Android application file (.apk). Our beta version only builds in debug mode, but soon you’ll be able to “sign” your applications so they can be uploaded to an app store, such as Google Play.

Currently, iOS, Windows and Blackberry are all grayed out. This only means they are on our roadmap to complete! First to tackle is iOS…

Stay tuned, more to come!

As always, we love hearing your feedback and suggestions. What do you think of the new Dynamic Export? Is there anything we missed or could do to improve it’s current state? We’re looking forward to hearing from  you!

Ben

I'm Ben, one of the co-founders of Codiqa. I like pushing pixels and building simple products. Minimalist at heart. Say hello to me on Twitter!

More Posts - Website

redirectron

Redirectron is a service from Drifty, which makes it easy to redirect mobile users to your separate mobile website. Its ultimate goal is to take the headache out of detecting mobile devices and redirecting them to the correct location.

Simply put:
• No worries about installing and paying for large server-side solutions.
• No worries about maintenance and keeping your detection data updated.
• No worries about loading large external JavaScript files.
• No worries about slowing down your website.
• No worries about any additional load on your servers.

How Does It Work?

how it works

Let’s say you operate a website at http://www.example.com/ and have also developed a mobile website at http://m.example.com/. Ideally, visitors on mobile devices with small displays (such as an iPhone) should view your content from your mobile website. Once an iPhone user visits http://www.example.com/, the detection script would determine that it is better for the device to view the http://m.example.com site. However, the trouble lies in correctly detecting if the person is viewing your website from a small display or a large display.

A common workaround is to use “user-agent sniffing”, but the problem lies in its accuracy. Usually, home-grown scripts will simply check if “iphone,” “android,” or “blackberry” in the user-agent string. While this method “works” on the phone you tested it on, the reality is, there are thousands of different types of user-agents, and they’re forever changing. What makes matters worse is that it is getting harder to tell the difference from a phone or a tablet, especially for Android devices.

The great news is that Redirectron does all of this work for you, and makes it extremely easy to setup- all at no cost to Codiqa users.

Desktop Site vs. Mobile Site

desktopvsmobile

The term “Desktop Site” is commonly used to describe websites with a wider format easily viewed by larger displays, like a desktop or laptop computer. A “Mobile Site” is a website that was built so it can fit within smaller displays, such as a mobile phone. Codiqa is great at building mobile sites.

Tablet devices, such as an iPad, Kindle Fire or Samsung Galaxy Tab, live in that gray area between a small display and a large display. In most cases we prefer tablets to view the desktop sites rather than mobile sites. While tablets are “mobile” in nature, as in they can be picked up easily and used on a subway, they still usually have a wide enough display that merits the desktop site.

Adding Redirectron To A Codiqa Project

To use Redirectron you must first be a Codiqa user and have created a project (if you haven’t created one yet you can sign-up for free and test it out, you’ll have a blast).

With your Codiqa account and project created you can now add Redirectron to any project using the Add-on’s page, which can be found in the header on Codiqa’s dashboard. Next find the Redirectron section (the one with the awesome robot) and click “Add to Project”. In the dialog simply click the project you would like to add Redirectron to. Each of your projects can have one Redirection account.

Redirectron Configuration

adding redirectron
In the “Desktop Site URL” input, simply enter the website address to your desktop version. In actuality we’re only looking for the hostname of your desktop site, such as www.mysite.com.

In “Mobile Site URL to Redirect To”, Redirectron needs to know what website to “redirect” mobile users to. This address needs to be more specific and include the scheme, hostname and path. For example, http://m.example.com/ is a complete URL (http:// is the scheme, m.example.com is the hostname, and / is the path).

Maintaining Website Paths

But wait, simply redirecting all mobile users to http://m.example.com/, no matter what desktop webpage they came from, can be frustrating for the visitor. For example, if a mobile user visited a specific page, such as http://www.example.com/article.html, even though they wanted to view the content at the path /article.html, they would always be redirected to http://m.example.com/. This can be upsetting for the visitor because they were expecting to read a specific article, but instead got bounced to the mobile homepage which didn’t contain the article.

Great news is that you can maintain the desktop path which they were initially loading, and dynamically send them to the mobile site’s version using the {path} parameter. For example, in the mobile site URL you could enter http://m.example.com/{path} and the desktop site path which the user came from would be maintained in the mobile site URL. In the previous example, if a mobile user viewed http://www.example.com/article.html they would then be redirected to http://m.example.com/article.html.

The {path} parameter could even be used as a querystring, such as http://m.example.com/?from={path}. Placing the path in the querystring could be used as a method for the mobile site to locate and load the correct content. The {path} parameter is optional, but is a useful tool for seamless mobile website integration.

Desktop Site Code Installation

After configuring Redirectron from the Add-ons page of Codiqa, your next step is to install the necessary script on your desktop website. It’s important to note that only your desktop site should have the Redirectron code installed. Again: Redirectron code should only be installed on your desktop site, the mobile site does not require the Redirectron code.

desktop redirectron code

The Redirectron code is non-blocking, meaning it will not hold up your visitor’s browser as the page loads. Because it is non-blocking we recommend the Redirection code should be placed in the <head> of your webpages, this way it’ll be faster at detecting if a visitor is on a mobile device or not. When a mobile device is detected they’ll quickly be redirected to the mobile site, otherwise nothing will happen for desktop users. If there are desktop web pages which should not have mobile detection, simply do not include the code on that web page. More information can be found at Redirection’s documentation.

Desktop Site Code

Place the following code into the <head> of each web page which should perform mobile redirection (Reminder: only your desktop site will need this code):

Could not embed GitHub Gist 6177223: Not Found

That’s it! Give it a shot and let us know how it goes. As always, we want to hear your feedback on how we can improve it.

Adam Bradley

Maker of Internet things focusing on web applications, mobile, responsive images, responsive web design and content delivery. Proud dad, husband, veteran and dogs' best friend. Swing by and say hello on twitter.

More Posts