Re: Web vs Native (was Re: HTML5 limitations?)

Wow! Quite the discussion! and here I was away from the list adding one last (hehe maybe not) feature to V1 of the SivaSiva app (hope to release by Aug 15) which was to create a "news channel" of course the obvious way to do this is have an HTML page on line, that you call into a browser

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-29 13:10, Jonathan Lynch via use-livecode wrote: So... if we use the wait command, and deploy to HTML5, the engine converts it to JavaScript with extra functions because the engine added in asynchronous timeouts? And you preserve all the variable values of the source LC script across

Re: Web vs Native (was Re: HTML5 limitations?)

Hi Jim, One can have interruptible animations by using a handler that progresses the movement a single step, then calls itself using a send-in-time construction to initiate the next step. I recently posted a momentum scrolling script on this list that uses this technique. Does that help?

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 1:14 PM, Mark Waddingham via use-livecode wrote: > > I think the first thing we would need would be builtin > gesture support. In this case, this isn't even 'a gesture has happened' > but 'it looks like a swipe is just starting' (I think at least). e.g. > swipeBegin / swipeContinue

Re: Web vs Native (was Re: HTML5 limitations?)

Hey, Mixed answer below: > - when the app needs access to the phone's functions (notifications, GPS, > screen dimming, text messages, etc) > There are Web APIs for: * Geolocation https://developer.mozilla.org/en-US/docs/Web/API/Geolocation * Notification (both local and push): - Local:

Re: Web vs Native (was Re: HTML5 limitations?)

Hey, I think I am on a special position to talk about this as I have been on the bleeding edge of the Web trenches for a while. Instead of boring everyone here to death, I will do a quick TL;DR first with the actual info and then digress a bit about the current situation. = WEB: * The

Re: Web vs Native (was Re: HTML5 limitations?)

Here is an example of using wait in my app... It seems to work better if I first load the map, then add markers from my database, rather than doing both at once. There is not a good trigger to detect when the map is fully loaded and displayed. So, I set an event listener for the page load, to

Re: Web vs Native (was Re: HTML5 limitations?)

You are right, Hermann - did not mean that to be mean-spirited to my home country, which I actually rather love. My apologies. I do think that "wait" can be useful sometimes, but not often. I was just surprised at the effort they are taking to reproduce "wait" in HTML deployment. Sent from

Re: Web vs Native (was Re: HTML5 limitations?)

Hi I took that to be a self-deprecating comment and not anything to be offended by unless your comment hermann is supposed to be ironic in some sense? Regards Lagi On 29 July 2017 at 13:51, hh via use-livecode wrote: > #wait > I don't miss the "wait" handler in

Re: Web vs Native (was Re: HTML5 limitations?)

#wait I don't miss the "wait" handler in HTML5 and I wouldn't miss it in LC Script. I even don't know of any use case where "send in " (which works perfectly in HTML5) isn't superior to "wait". Especially when connected to move/animation. Also I don't miss "wait" in LC Builder. There OnTimer() is

Re: Web vs Native (was Re: HTML5 limitations?)

So... if we use the wait command, and deploy to HTML5, the engine converts it to JavaScript with extra functions because the engine added in asynchronous timeouts? And you preserve all the variable values of the source LC script across these multiple functions? This was the easy solution?

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-29 07:11, J. Landman Gay via use-livecode wrote: On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote: P.S. At some point I'll write at length about the 'wait' problem in HTML5. Whilst I try not to let myself be kept awake at night by engineering problems related to work - if

Re: Web vs Native (was Re: HTML5 limitations?)

Indeed! That is the crux of the problem. Neither Android nor iOS have 'wait' (or the underlying OS feature you need to implement it) either. However those platforms have general threads so you can emulate it. HTML5 does not have general threads (although it probably will in about 2-3 years -

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 1:14 PM, Mark Waddingham via use-livecode wrote: What specific problem do we really need to solve... i.e. Is card-level swiping generally important enough to warrant an approach which isn't quite so general (very specific, one might say!)? The thing here is that we could well

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote: P.S. At some point I'll write at length about the 'wait' problem in HTML5. Whilst I try not to let myself be kept awake at night by engineering problems related to work - if ever there was one which did, it would be that one! When

Re: Web vs Native (was Re: HTML5 limitations?)

I thought that JS/HTML5 did not have a wait function? One can loop the engine, which is horrible, or one can set timeouts for functions. What functionality do you access to induce a wait? Sent from my iPhone > On Jul 28, 2017, at 8:29 PM, Mark Waddingham via use-livecode >

Re: Web vs Native (was Re: HTML5 limitations?)

Hi Hermann, First of all please don't take any offence at my email as none was intended. I was mainly trying to explain that whilst there are many things the HTML5 engine does not do, which means many stacks will not work without changes/workarounds (indeed, somewhat significant ones) -

Re: Web vs Native (was Re: HTML5 limitations?)

On 07/28/2017 11:41 AM, Mark Waddingham via use-livecode wrote: This is, of course, why I sometimes take 1000 words to say things which could have been said in 10 ;) Wouldn't have it any other way -- Mark Wieder ahsoftw...@gmail.com ___

Re: Web vs Native (was Re: HTML5 limitations?)

Mark Waddingham wrote: > On 2017-07-28 20:17, Richard Gaskin via use-livecode wrote: >> I think we're closer on this than might have originally seemed: > > Indeed - on this and most things I think. > > I've always assumed that you tend to ask certain questions, or phrase > things in a certain in

Re: Web vs Native (was Re: HTML5 limitations?)

> Mark wrote: > However, there is one VERY important point I do need to make. It is easy > to get hang up on saying 'oh the HTML5 engine doesn't do this, and oh it > doesn't do that' - and this might well be true. *However* the only important > metric in this regard is - does it allow a suitable

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 20:17, Richard Gaskin via use-livecode wrote: I think we're closer on this than might have originally seemed: Indeed - on this and most things I think. I've always assumed that you tend to ask certain questions, or phrase things in a certain in way to give us (well, me,

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 12:53 PM, J. Landman Gay via use-livecode wrote: I think we could discuss here on the list how it might work and then add to the feature request if we come up with something. After writing my response, I see that Richard has provided a nice description in the bug report that covers

Re: Web vs Native (was Re: HTML5 limitations?)

Mark Waddingham wrote: > On 2017-07-28 18:34, Richard Gaskin via use-livecode wrote: >> A sense of smooth liquid flow is the hallmark of modern UI. If >> support for this were limited to one widget that requires JavaScript, >> we might as well use the other tools you mentioned above. > > This

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 12:01 PM, Mark Waddingham via use-livecode wrote: That is the standard process for all enhancement requests. They are HIBERNATED until we have the time to evaluate and prioritise - if we were to do anything else, we would end up never getting any work done - and work we are doing

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 19:01, Mark Waddingham via use-livecode wrote: Right now JS/HTML5/CSS etc. has the edge over LiveCode in creating these rich UIs. Now, to be honest, the acceleratedRendering mode of LiveCode (which has been around for years) is no different from the underlying tech in browsers

Re: Web vs Native (was Re: HTML5 limitations?)

On Fri, Jul 28, 2017 at 11:43 AM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > > At the end of the day, it might not be that making it synchronous *is* the > solution, but instead tweaking engine syntax and semantics to make it > easier to deal with this

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 18:34, Richard Gaskin via use-livecode wrote: A sense of smooth liquid flow is the hallmark of modern UI. If support for this were limited to one widget that requires JavaScript, we might as well use the other tools you mentioned above. This is simply not true. All tools have

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 18:28, William Prothero via use-livecode wrote: on myRequest —send a POST or GET request, whatever, with a callback handler specified. —display a mask that inhibits new mouse clicks and sets a busy icon. end myRequest on myCallbackHander myReturnData —do whatever you want

Re: Web vs Native (was Re: HTML5 limitations?)

Sannyasin Brahmanathaswami wrote: > As for web app vs native app, @Richard Gaskin You *can*, obviously, > build a "web app" (html5+js+css) and package it in the app and run > it off line. another lad here on our team builds in ionic/React > /Angular. But his app is "native" to the phone,

Re: Web vs Native (was Re: HTML5 limitations?)

It requires setting up chained handlers on both the LC and JS side, but as long as you structure it well, it is not that bad. I can tell you that for working with maps, it is essential. Sent from my iPhone > On Jul 28, 2017, at 12:28 PM, William Prothero via use-livecode >

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-26 23:06, hh via use-livecode wrote: There are, sadly, still very basic things missing, which make the HTML5 standalone builder, TMHO, not yet ready for "beta"-state. Well - yes - the 'beta' state as I mentioned was a slip (mainly in that we don't do 'beta' in our dev process as I

Re: Web vs Native (was Re: HTML5 limitations?)

Folks: As a long term Director developer, I found the use of listeners and callbacks to be quite easy to implement. I don’t see the problem. on myRequest —send a POST or GET request, whatever, with a callback handler specified. —display a mask that inhibits new mouse clicks and sets a busy

Re: Web vs Native (was Re: HTML5 limitations?)

Although I am one of the people calling for more browser widget development... I have my doubts about the ability to make it synchronous with LC. JavaScript is not even reliably synchronous with HTML5, forcing JS developers to use callbacks and event listeners in weird places. Unless you guys

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 16:47, Sannyasin Brahmanathaswami via use-livecode wrote: Hence oft-repeated prayer that we get the browser "widget" to become a true member of the LC message hierarchy, they we can leverage the web apps eye candy layer (easy to build, responsive, CSS is already done for us…) with

Re: Web vs Native (was Re: HTML5 limitations?)

Matt wrote: Except that they've aged out of the phase where it's easy to learn new things. So they feel like an idiot baby and it takes way too much effort to push through the learning curve. LOL, hence my surprise after listening to some complaints by older folks about the

Re: Web vs Native (was Re: HTML5 limitations?)

> On Jul 27, 2017, at 10:48 AM, Matt Maier via use-livecode > wrote: > High market penetration of smartphones doesn't mean anyone actually has any > idea how to use their smartphone. Most people are at about the > Fischer-Price My First Shapes and Colors level.

Re: Web vs Native (was Re: HTML5 limitations?)

Word. I barely have any experience and I've already run into multiple users/customers who think that "add to homescreen" is impossible hacker magic. High market penetration of smartphones doesn't mean anyone actually has any idea how to use their smartphone. Most people are at about the

Re: Web vs Native (was Re: HTML5 limitations?)

Which point illustrates something I'm sure seasoned developers have known for a long time: There is no way to write an app so that it will satisfy everyone, especially these days with all the ways to deliver an app! To illustrate, I had a gal here in the office lose some documents, because I

Re: Web vs Native (was Re: HTML5 limitations?)

hh wrote: >> RG wrote: >> - What are the use-cases where a native app is a better choice than >> a web app? >> - What are the perceived benefits of web apps and native apps? >> The first question is about actual capabilities, and the second >> is about the psychological drivers of clients and

Re: Web vs Native (was Re: HTML5 limitations?)

Add to list as necessary. I've already pulled in a few items from other posts. We can come up with a referendum/consensus on the topic. Traditional Apps: UP SIDE Better performance No dependent on an internet connection (if server is not installed locally) Many people still prefer to own

Re: Web vs Native (was Re: HTML5 limitations?)

On Wed, Jul 26, 2017 at 5:27 PM, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > hh wrote: > >> RG wrote: > >> My bigger question here is what needs to be delivered specifically > >> in a web browser window vs a native app, and why? > > > > This questions browsers ("the

Re: Web vs Native (was Re: HTML5 limitations?)

> RG wrote: > - What are the use-cases where a native app is a better choice than a web app? > - What are the perceived benefits of web apps and native apps? > The first question is about actual capabilities, and the second is about the > psychological drivers of clients and customers, which may

Re: Web vs Native (was Re: HTML5 limitations?)

hh wrote: >> RG wrote: >> My bigger question here is what needs to be delivered specifically >> in a web browser window vs a native app, and why? > > This questions browsers ("the web") as platform in general. > TMHO, you are too late with that question, by 25 years. Perhaps just poor writing on

Re: Web vs Native (was Re: HTML5 limitations?)

> RG wrote: > My bigger question here is what needs to be delivered specifically > in a web browser window vs a native app, and why? This questions browsers ("the web") as platform in general. TMHO, you are too late with that question, by 25 years.

Re: Web vs Native (was Re: HTML5 limitations?)

hh wrote: >> Mike K. wrote: >> My perception is that the web experience is very close to a desktop- >> native experience, and the two are almost interchangable. Running an >> app in a browser feels and works almost the same as a native one >> does. > > The HTML5 standalone builder... ... >

Re: Web vs Native (was Re: HTML5 limitations?)

> Mike K. wrote: > My perception is that the web experience is very close to a desktop-native > experience, and the two are almost interchangable. Running an app in a > browser feels and works almost the same as a native one does. The HTML5 standalone builder has greatly improved within the last

Re: Web vs Native (was Re: HTML5 limitations?)

My perception is that the web experience is very close to a desktop-native experience, and the two are almost interchangable. Running an app in a browser feels and works almost the same as a native one does. However, once you get to mobile, the web app experience is nowhere on par. Even mobile

Re: Web vs Native (was Re: HTML5 limitations?)

> JLG wrote: > In my case, the app is courseware and students are complaining they want it > to work on their mobile devices. Some don't have laptops and don't want to > use the computer lab. The options are to create mobile apps or alternately > run it in the mobile browser. There is

Re: Web vs Native (was Re: HTML5 limitations?)

J. Landman Gay wrote: > In my case, the app is courseware and students are complaining they > want it to work on their mobile devices. Some don't have laptops and > don't want to use the computer lab. That's an interesting subset. Do you have a feel for what percentage of that audience

Re: Web vs Native (was Re: HTML5 limitations?)

On July 26, 2017 9:20:17 AM Richard Gaskin via use-livecode wrote: I believe Rick's "Why" here is key to much of what we may be doing over the next couple years. In my case, the app is courseware and students are complaining they want it to work on their

Re: Web vs Native (was Re: HTML5 limitations?)

Roger Eller wrote: > As for in-house or "corporate" mobile, they seem to also want > everything to be web based as well. I tried real hard to get > LiveCode accepted for mobile development... Well at least they're consistent in their desire for web apps. I keep coming across people who insist

Re: Web vs Native (was Re: HTML5 limitations?)

As for in-house or "corporate" mobile, they seem to also want everything to be web based as well. I tried real hard to get LiveCode accepted for mobile development, but they only wanted a tool that could create secure html5 apps. This was back when LC html5 was only in early planning. ~Roger

Web vs Native (was Re: HTML5 limitations?)

I believe Rick's "Why" here is key to much of what we may be doing over the next couple years. We developers currently find ourselves in a very strange place: On desktop, the requests are "Web! Web! Web!" On mobile, they're "Apps! Apps! Apps!" If the web offers advantages that can't be