In-App Purchasing for Amazon and Samsung App Stores

by Panagiotis Merakos on March 10, 2014 2 comments

During the last 2.5 months I have been working on extending in-app purchasing (IAP) feature to apps distributed through Amazon Appstore and Samsung Apps Store. I am excited to work on such a ‘hot’ topic. A quick introduction :

What is in-app purchasing?

With in-app purchasing you can sell digital goods (lives/bullets/extra levels to a game, access to a service etc) from within your app.

Why to use IAP in my app?

There are various ways to make money from your app. All of them fall into one of the following three categories:

  1. Charge users for downloading your app (paid model)
  2. Offer your app for free and charge for additional/premium features (free with IAP)
  3. Charge for both the app and additional features (paid with IAP)

It seems that the “freemium” (i.e. free app with IAP) business model is proved to be the most profitable with the largest revenue shares :

inapp3

source : Distimo Publication – February 2014

What will change in the existing Livecode API for in-app purchasing?

The Livecode engine currently supports in-app purchasing for apps distributed through the Google Play Store (formerly Android Market), as well as the Apple AppStore. This support will now be extended so that apps distributed through other avenues (the Amazon & Samsung app stores) can make use of the in-app purchase features provided. For this reason, new LiveCode commands, functions and messages will be added. However, all of the existing (IAP-related) commands and functions will still be supported (for Google Play Store and Apple AppStore).

Why is this important?

From the developer’s point of view, being able to distribute a freemium app from multiple channels, means higher revenue. Moreover, they do not have to worry about how each store-specific IAP API works, since the same code will work across all stores. All they have to do is just select the store in the Standalone Application Settings for the app, and then the LiveCode IAP API will “behind the scenes” communicate with each store-specific IAP API, depending on which store the developer has selected to distribute the app through.

inapp2

IAP APIs for Samsung, Amazon and Google

The new LiveCode IAP API will allow the user to query for specific product information (such as price, description etc) before they make a purchase, and will support purchasing of subscription items for all available stores.

I will keep you posted on the progress of the project, so stay tuned!

read more
Panagiotis MerakosIn-App Purchasing for Amazon and Samsung App Stores

Diverging and Merging

by Ali Lloyd on March 7, 2014 No comments

As you probably already know we are getting close to the first developer preview of the Unicode-compatible LiveCode 7. It’s very exciting for me personally, as I have been working on this in one way or another since I started here in November 2012. I knew there was a lot to do, but suffice it to say that at the time I didn’t realise quite how much! In many ways it has been the perfect introduction to the LiveCode engine for me – a not-so-whistlestop tour around all the areas touched on by the refactoring project, which is to say almost all of it.

One of the challenges of maintaining the refactored engine is keeping it up to date, by continually merging in new bug fixes and features. It can already be a little tricky to resolve merge conflicts when so much of the engine has changed, but in many cases code has been moved from its original location to a new file. Sometimes this can result in code getting merged automatically into blocks of code that are no laonger executed, so we’ve had to come up with a system to ensure than any updates which land in the old location are flagged up.

Challenged by Ben to come up with a name for this system, I opted for syntax caravan- the idea being that the syntax branch is diverging from the main branch (going on holiday), but needs to keep being updated on what the main branch is doing (needs to bring the main branch in a caravan). Ok it doesn’t quite work as an analogy, but I was thinking fast and I was asked to be cryptic! It’s a bit snappier than ‘the occasional telephone call from master to tell syntax what it is up to’.

Here is a screenshot of the tool written by Seb which shows the syntax caravan in action:

click image for full size preview

caravan2

You can see that the usePixelScaling property, and a change to the pixelScale property, have been happily merged by Git. Unfortunately the active version of that code now resides in a completely different file. Thanks to the syntax caravan we can ensure that none of these things get lost in the merge. It shouldn’t be too long now before the syntax branch comes home, and we can put the caravan away for good. Or at least until the next engine overhaul…

read more
Ali LloydDiverging and Merging

LiveCode Server

by David Williams on March 6, 2014 5 comments

Here at On-Rev, we make extensive use of LiveCode Server internally for scripting – you’ll see a lot more filenames ending in .lc than you might in .sh, purely for the reason that LiveCode Server is great for making scripts that are a lot more readable than, say, a bash script, and we can drop in shell commands with ease where necessary.

One recent feature that was introduced in LiveCode 6.6 was the ability to use hashbangs (#! /path/to/livecode) in LiveCode server scripts instead of script open and close tags (<?lc ?>). This means that we can have scripts which look like this:

#!/path/to/livecode-server
put “hello world at” && the millisecs

Instead of this:

<?lc
put “hello world at” && the millisecs
?>

The difference is that the latter has to be passed as a file to the LC Server exectuable, which then parses the code for output. This makes sense where LC Server is integrated into a web server software for serving webpages, but if we were doing this in a command line, it would look like this:

root@mybox [~]# /path/to/livecode-server ./script.lc

Whereas by using hashbangs, we can now execute the script directly, as the script contains the information for how it should be executed:

root@mybox [~]# ./script.lc

This seems like a minor change, but it brings the LC Server engine closer to how scripting for system utilities should function in a Unix environment, and allows me to tidy up some of the internal systems we use a little bit.

Additionally, work on the On-Rev client has been ongoing and we hope to release an update as soon as some of the last technical hurdles are overcome – we hope to send out a notification about this to all our On-Rev customers in the near future.

read more
David WilliamsLiveCode Server

LiveCode CoderDojo

by Elanor Buchanan on March 4, 2014 No comments

Over the last year or so we’ve done quite a lot of training events, for programmers, teachers and kids but last month we did something special, we ran 2 CoderDojo events in our office here in Edinburgh.

CoderDojo is a global, open source, volunteer led organisation providing free coding clubs for young people. So it’s perfect of LiveCode to be involved with. We organised and ran the sessions here with the help of Craig, from CoderDojo Scotland.

Although the sessions were aimed at 12-17 year olds our attendees varied quite a lot in age and coding experience, from none at all to one boy who uses LiveCode in his high school computing classes and likes it so much he came to do more in his free time, although that might have been for the tiny bit of coursework assistance we gave him. Regardless of age or experience we saw a lot of impressive apps, a lot of creativity, and we had a lot of fun too.

The idea behind the session was to introduce LiveCode, show how quick and easy it is to make an app, demonstrate some interesting features and give the kids some free reign to personalise their apps.

The app we created was an animated e-book called Balloon Adventure, we covered importing images, using fields, buttons and dialogs, creating animations, controlling a player, collecting points, personalising and tailoring the look of the app within LiveCode and much more.

During the session we asked the attendees to guess some of the LiveCode commands, functions and properties we would use to achieve certain results, and in most cases they got it right, although we often had to ask them to guess even simpler terms than the ones they initially guessed, it’s also surprisingly difficult to ask someone what the name of the command they would use to animate the balloon along the path they drew might be, without giving the answer away by using the word “move”.

These sessions were a lot of fun, for myself and Neil, and the attendees seemed to enjoy them. It was great to see LiveCode being used in this way and the variety and creativity of the apps we saw, even just using a small set of options within LiveCode was great to see. We are looking forward to doing more events like this in the future.

If you are interested in any of the materials used during these sessions we would be happy to share them. You can request them by emailing support@runrev.com

read more
Elanor BuchananLiveCode CoderDojo

7.0 – Unicode Strikes Back

by Fraser Gordon on February 27, 2014 14 comments

It has been a number of months since Ali reported our progress on the engine refactoring project and the integration of Unicode into LiveCode (Slaying the Unicode Monster) and in that time, much has changed. The project is nearly complete and, as Kevin said yesterday, we are approaching a DP release.

Supporting Unicode and international text has required extensive changes throughout the engine – too extensive to cover in a single blog entry – so today I’ll explain the changes to one of the most visible parts of LiveCode: fields.

In the current releases of LiveCode, it is possible to use Unicode text in fields. Unfortunately, it requires special syntax and can be a bit cumbersome to manipulate properly. In addition, the support is fairly rudimentary and doesn’t work properly for languages requiring complex text layout (for example, Arabic).

7.0 will change all that – Unicode text in fields (and throughout the engine) is manipulated the same way as any other text. In fact, the engine doesn’t distinguish between Unicode text and “plain” text anymore – they are both just text. But that’s a story for another time.

Screen Shot 2014-02-27 at 10.50.21Most of the changes in the field to support Unicode are “below-the-hood” and won’t be immediately apparent. They have, however, allowed for a much greater deal of flexibility in how text in fields is processed and I’ll summarise what this has allowed us to do:

East Asian languages such as Chinese and Japanese. Previously, these could be entered but the field had difficulty with certain characters that required a certain type of Unicode encoding called “surrogate pairs” – the components of these pairs were treated as separate characters, causing problems when one of them was deleted or had its style changed.

Complex scripts where multiple character fragments combine to form one graphical character (called a “grapheme”). For text manipulation, these are now treated as single characters (and new chunk types “codepoint” and “codeunit” have been added for those who need to access the individual components).

Cursor navigation working appropriately for non-English text. Navigating left and right through a field happens on grapheme boundaries, ensuring that the cursor never ends up between a character and its accent. The keyboard commands for moving forwards and backwards by whole words also works for text that doesn’t use spaces as word separators (e.g. Chinese).

Right-to-left and bidirectional text. Mixing left-to-right and right-to-left languages (e.g. Hebrew and Arabic) text in a field now lays text out in the correct order, including the situation when LTR is embedded within RTL or vice-versa.

All of this is available without any extra work on the part of a developer creating a LiveCode app – our goal with our Unicode support is to make it just as easy to create an app with Unicode support as without. We hope you’ll be pleased with the result!

read more
Fraser Gordon7.0 – Unicode Strikes Back

LiveCode 6.5

by Ben Beaumont on December 6, 2013 No comments

Resolution Independence

Your app scaled beautifully on any device

Mobile app development is now even easier with LiveCode 6.5. Your stack can now be scaled to run fullscreen on ANY device, no matter its size or aspect ratio. What’s more, LiveCode fully supports high density screens by upscaling text, vectors and automatically substituting in high quality images. Your apps now look stunning on any device.

Best of all, these features are built right into LiveCode and are enabled with just ONE LINE OF CODE!

How to use

No changes and just one line of code

To use this feature with existing stacks requires no changes.Simply tell LiveCode to scale and what your preferred scaling method would be. LiveCode will take care of the rest.

set the fullscreenmode of this stack to “exactFit”

   

read more
Ben BeaumontLiveCode 6.5

6.1.2 Brings iOS 7 Support

by Heather Laine on October 18, 2013 No comments

6.1.2 Released
ios 7We are pleased to announce the release of LiveCode 6.1.2. This is a stable release containing more than 30 bug fixes and support for xCode 5.0 and iOS 7. We would recommend all 6.1 users upgrade to this release. It is available for both Community and Commercial users. If you have a Commercial 6.x license this release will have automatically become available in your LiveCode account.

The principle reason for existance for this minor point release is to add support for the latest iOS, however as usual we have taken the opportunity to fix various issues and squeeze in a number of enhancements for your delight. Here’s what 6.1.2 has for you.

Engine Changes

iOS 7/Xcode 5 Support
Support has been added to the engine and IDE to allow for iOS builds using Xcode 5.0. This means that OS 10.8 users (required by Xcode 5.0) will need to have Xcode 5.0 installed and set up in LiveCode’s preferences in order to produce Arm v7 builds. Arm v6 builds will still be produced using Xcode 4.4 (the last version to support Arm v6).

The table below details the versions of Xcode LiveCode requires on each platform to produce the given build type. In order to produce universal builds both the Arm v6 and Arm v7 Xcode SDKs will be required.

Platform Arm v6 Arm v7
10.6 Xcode 4.2 (iOS 5.0) Xcode 4.2 (iOS 5.0)
10.7 Xcode 4.3 (iOS 5.1) Xcode 4.6 (iOS 6.1)
10.8 Xcode 4.3 (iOS 5.1) Xcode 5.0 (iOS 7.0)

In addition to the above, the new iOS 7 icon sizes can be specified in the standalone builder. They are sized as follows:

  • Retina iPhone: 120×120
  • iPad: 76×76
  • Retina iPad: 152×152

Better Quality Printing on Mac
When printing on Mac, two things have been improved. The first is that semi-transparent groups (with default ink – copy / srcOver) will render directly rather than being rasterized first. The second is that PNG and JPEG images will pass their data directly through to the printer driver. The end result is that scaled images will print at higher resolution than they did before in many more cases.

URL Operations Sometimes Fail on Android
There is a bug in the Android Java HTTP layer which can cause URL operations to fail (https://code.google.com/p/google-http-java-client/issues/detail?id=116). This problem seems to be related to keep-alive connections, thus until this bug is addressed in Android the engine will now turn off keep-alive on startup.

Support for Arm V6 iOS Builds Dropped
The earliest version of iOS supported by LiveCode is 4.3. Since iOS 4.3 only runs on Arm v7 (and newer) devices, support for Arm v6 (and subsequently universal builds) has been dropped. This has in turn simplified the versions of Xcode a user needs to have installed in order to perform iOS device builds:

Platform Xcode Version iOS SDK Version
10.8 5.0 7.0
10.7 4.6 6.1
10.6 4.2 5.0

Applescript Now Works on LiveCode IDE
This issue has been fixed. It was caused by incorrect naming of the rsrc file – it was LiveCode.rsrc rather than LiveCode-Community.rsrc or LiveCode-Commercial.rsrc. (The name of the rsrc file has to match the name of the executable file within the bundle).

Key Code Parameter to RawKey Messages No Longer Always Zero on Mobile
The rawKey messages will now give pass the ASCII code of ASCII characters to rawKeyDown/Up when pressed. This is consistent with the Desktop’s handling of the rawKey messages.

Spaces No Longer Required in Date Formatting
Date format string parsing has been made less strict in its processing, now collapsing one or more spaces together to allow a ‘ ‘ in a format string to match one or more input spaces. Additionally, spaces in the input after a formatting specifier was successfully matched are ignored. With these changes, both “10:41 PM” and “10:41PM” are accepted as valid times; previously, only the former was acceptable.

Caseless Comparison Now Working Correctly on Linux
For Linux distributions having their locale set to something other than ISO8859-1, caseless comparison was not working correctly. This has been fixed.

Ensure Caseless Comparison Works on Linux Server
This problem was fixed on the Desktop as Bug 11160 and has now been iterated to the Server build.

Offline Activation Now Working in Ubuntu
The installer now does not offer to launch LiveCode after installation as root (e.g. via su or sudo) on Linux in order to prevent the product from creating its activation files with the wrong permissions. Instead, LiveCode should be launched in the normal way after installation and activation occurs then.

A full fix list and more details can be found in the release notes for this edition, here.

For more news and articles this week please visit our newsletter, revUp.

read more
Heather Laine6.1.2 Brings iOS 7 Support

LiveCode 6.1.2

by Ben Beaumont on October 18, 2013 No comments

6.1.2 Brings iOS 7 Support

The latest stable release offers over 30 enhancements as well as the awaited iOS 7 support

ios 7We are pleased to announce the release of LiveCode 6.1.2. This is a stable release containing more than 30 bug fixes and support for xCode 5.0 and iOS 7. We would recommend all 6.1 users upgrade to this release. It is available for both Community and Commercial users. If you have a Commercial 6.x license this release will have automatically become available in your LiveCode account.

The principle reason for existence for this minor point release is to add support for the latest iOS, however as usual we have taken the opportunity to fix various issues and squeeze in a number of enhancements for your delight. Here’s what 6.1.2 has for you.

Engine Changes

iOS 7/Xcode 5 Support
Support has been added to the engine and IDE to allow for iOS builds using Xcode 5.0. This means that OS 10.8 users (required by Xcode 5.0) will need to have Xcode 5.0 installed and set up in LiveCode’s preferences in order to produce Arm v7 builds. Arm v6 builds will still be produced using Xcode 4.4 (the last version to support Arm v6).

The table below details the versions of Xcode LiveCode requires on each platform to produce the given build type. In order to produce universal builds both the Arm v6 and Arm v7 Xcode SDKs will be required.

Platform Arm v6 Arm v7
10.6 Xcode 4.2 (iOS 5.0) Xcode 4.2 (iOS 5.0)
10.7 Xcode 4.3 (iOS 5.1) Xcode 4.6 (iOS 6.1)
10.8 Xcode 4.3 (iOS 5.1) Xcode 5.0 (iOS 7.0)

In addition to the above, the new iOS 7 icon sizes can be specified in the standalone builder. They are sized as follows:

  • Retina iPhone: 120×120
  • iPad: 76×76
  • Retina iPad: 152×152

Better Quality Printing on Mac
When printing on Mac, two things have been improved. The first is that semi-transparent groups (with default ink – copy / srcOver) will render directly rather than being rasterized first. The second is that PNG and JPEG images will pass their data directly through to the printer driver. The end result is that scaled images will print at higher resolution than they did before in many more cases.

URL Operations Sometimes Fail on Android
There is a bug in the Android Java HTTP layer which can cause URL operations to fail (https://code.google.com/p/google-http-java-client/issues/detail?id=116). This problem seems to be related to keep-alive connections, thus until this bug is addressed in Android the engine will now turn off keep-alive on startup.

Support for Arm V6 iOS Builds Dropped
The earliest version of iOS supported by LiveCode is 4.3. Since iOS 4.3 only runs on Arm v7 (and newer) devices, support for Arm v6 (and subsequently universal builds) has been dropped. This has in turn simplified the versions of Xcode a user needs to have installed in order to perform iOS device builds:

Platform Xcode Version iOS SDK Version
10.8 5.0 7.0
10.7 4.6 6.1
10.6 4.2 5.0

Applescript Now Works on LiveCode IDE
This issue has been fixed. It was caused by incorrect naming of the rsrc file – it was LiveCode.rsrc rather than LiveCode-Community.rsrc or LiveCode-Commercial.rsrc. (The name of the rsrc file has to match the name of the executable file within the bundle).

Key Code Parameter to RawKey Messages No Longer Always Zero on Mobile
The rawKey messages will now give pass the ASCII code of ASCII characters to rawKeyDown/Up when pressed. This is consistent with the Desktop’s handling of the rawKey messages.

Spaces No Longer Required in Date Formatting
Date format string parsing has been made less strict in its processing, now collapsing one or more spaces together to allow a ‘ ‘ in a format string to match one or more input spaces. Additionally, spaces in the input after a formatting specifier was successfully matched are ignored. With these changes, both “10:41 PM” and “10:41PM” are accepted as valid times; previously, only the former was acceptable.

Caseless Comparison Now Working Correctly on Linux
For Linux distributions having their locale set to something other than ISO8859-1, caseless comparison was not working correctly. This has been fixed.

Ensure Caseless Comparison Works on Linux Server
This problem was fixed on the Desktop as Bug 11160 and has now been iterated to the Server build.

Offline Activation Now Working in Ubuntu
The installer now does not offer to launch LiveCode after installation as root (e.g. via su or sudo) on Linux in order to prevent the product from creating its activation files with the wrong permissions. Instead, LiveCode should be launched in the normal way after installation and activation occurs then.

A full fix list and more details can be found in the release notes for this edition, here

read more
Ben BeaumontLiveCode 6.1.2