10 things you didnt know about LiveCode…well maybe.

by Steven Crighton on March 12, 2014 2 comments

Hi, I’m Steven. When I decided to write this blog post, I started to think … what can I write about? I had a browse through the great blog posts that came before me and It appeared obvious, you love the tech talk.

Being in Digital Marketing, what could I offer you in terms of tech talk that rivals what our incredible development team are talking about? It was at this point I got smart. My marketing genius shone through!

I challenged the dev team to come up with 10 things that they think are very useful in LiveCode but most users might not know about it.

A tricky challenge, considering that the experts in our community can likely show us a thing or two on how to use the LiveCode product, but the challenge was accepted.

Did I get 10 things from the team? Sure. Did I get 10 things that things that you don’t know about LiveCode? I guess that’s up to all of you, from beginners to experts, to let me know in the comments.

A Day in the Frontline. How important is Customer Support?

by Neil Roger on March 11, 2014 No comments

When the time comes to buying a new product, I have always felt that great customer support is key when making your decision.

Imagine the situation of being lumped with a $500 dent in your wallet (or purse) just because you don’t know how to get started. It wouldn’t make you feel particularly great would it? This type of situation can also apply to users, who are more familiar with your product and are considering a purchase.

Knowing that they have access to a basic level of support, with the option of upgrading to a something more tailored, gives them the confidence and final push they need to help them part with their hard earned money.

So what makes good customer support?

Receiving an answer to your question is a good start but its the personal touch that makes customers really appreciate your service. There is nothing better than creating a rapport with a customer and getting to know them on a more personal level. When a customer responds with “its great to hear from you again Neil” it really does make make the job worthwhile. (Receiving thank you chocolates is also a bonus) although my wife would probably tell me I don’t need them.

Our users are at the heart of LiveCode and we would not be here without them. I personally strive to ensure that I am consistently providing the best customer service possible and will always respond to every query I receive, no matter how big or small it may be. Whether it be someone starting out looking for some advice, to a pro support user with an intensive stack related question, our support channels are always there to be used and we will do our best to help. I like to encourage users to feel comfortable and confident to approach me, which I think is key to a successful Customer Service experience.

There are various avenues available for receiving support with LiveCode, with your first point of contact generally being support@runrev.com. Depending on your request, we will try to point you in the right direction and help you as much as possible. If you require more involved support (e.g. intense stack/scripting) then we will mention the various support packages that we have which will allow us to assist you. No matter how many questions you need to ask we will support you all the way until you find the resolution you need.

Along with this direct support path, we also have our more community based support in the form forums which can be found here: http://forums.runrev.com

The other Support systems we provide are also fantastic resources filled with second to none content, the additional links to these can be found at the end of this blog so please feel free to have a good look.

We have a very active and outstanding community who are always willing to share their wealth of knowledge. The Forums, Stackoverflow and Lists are also actively managed by the RunRev staff, which is fantastic as it allows them to input their vast amounts of knowledge regularly, therefore allowing support to be available on a more regular and faster pace.

I hope this has given you some insight into support RunRev and if you by chance require some LiveCode related help in the future, please do not be afraid to ask. (we don’t bite).

Link information: Stackoverflow LiveCode Use List

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:

Charge users for downloading your app (paid model)
Offer your app for free and charge for additional/premium features (free with IAP)
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 :

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.

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!

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

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…

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.

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

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.

Most 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!

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”

10 things you didnt know about LiveCode…well maybe.