Date   
Re: Should I bundle Rubik.bbc with the Android edition? #poll

Richard Russell
 

On Tue, Feb 27, 2018 at 01:09 am, dai_m_leeds wrote:
I looked at the BBCSDL download page,where it says the download is 7.3 MB,
That page is out of date; you will find that I state in my release announcement that the size is 8.1 Mbytes (as a rule it increases at each new release).

> Obviously if that compresses quite substantially

I stated in the poll question "
there are 6 Mbytes of data tables (less when zipped)" and I'm sure you know that it is not uncommon for Zip to halve the length of a file.  As it turns out that's almost exactly what it achieves in this case.  So the 34% increase should be about right.

Richard.

Re: BBC BASIC for iOS?

Richard Russell
 

On Tue, Dec 19, 2017 at 08:41 am, Richard Russell wrote:
So there are many issues to resolve before an iOS edition could be contemplated, and there may not be solutions for all of them. 
I've 'acquired' a hand-me-down iPhone (5S) from SWMBO, which has prompted me to take an interest in this topic again.  One thing I've definitely established is that iOS does not allow arbitrary code execution (it's not an App Store limitation, iOS itself prevents it) which of course means that neither BBC BASIC's assembler (not that we have one for 64-bit ARM!) nor the CALL statement and USR function, would be usable.  Considering how important the ability to run machine code is to BBC BASIC (for example some of the libraries depend on it, notably SOCKLIB and SORTLIB in BBCSDL) this is problematical.

The issue of SORTLIB is the more easily worked around, because it is of course possible to implement the same functionality in BASIC code.  It would only run at a fraction of the speed, but it might be good enough for some applications.  There is also the possibility, in principle, of adding a native SORT keyword to BBC BASIC (many BASICs do have that capability).

I don't know of any workaround for SOCKLIB however.  SDL_net, unfortunately (and stupidly in my opinion) provides no non-blocking 'read from network' capability, which is frequently a requirement - to be able to get on with other things, or monitor for an abort, while waiting for data to arrive.  I solve that at present by performing the 'blocking' read in another thread, but of course the only way to create a new thread in BBC BASIC is to use assembler code.

So, given all that, what is the consensus of opinion on whether developing an iOS edition of BBCSDL would be worthwhile or not?  I've always argued that BBC BASIC without an assembler isn't truly BBC BASIC, but you can't fight Apple!

Richard.

dlgdemo with keypad

Ian_Wade_G3NRW
 

Richard

I have decided that your Android dlgdemo example program will act as a helpful starting point for some simple apps that I want to write. I wonder if you have incorporated the keypad into dlgdemo, so that it becomes possible to enter text into some of the dldgdemo dialog boxes.

Or is this simple task left as an exercise for the reader?

--
Ian

Re: dlgdemo with keypad

Richard Russell
 

On Wed, Feb 28, 2018 at 06:22 am, Ian_Wade_G3NRW wrote:
Or is this simple task left as an exercise for the reader?
I don't think it is a "simple" task, because it would involve modifying the library (and you definitely don't want to do that, because I'm making changes to that library on an almost daily basis as I try to make things 64-bit compatible - it's an enormous pain)!

As I said before, dialogue boxes are largely foreign to Android; I don't think I've seen a single Android app with what could be described as a conventional dialogue box as part of its UI.  For that reason it would probably have been better if I had omitted dlgdemo.bbc from the Android edition; it's there because it's included with all the 'desktop' editions and I forgot to remove it, for want of a better explanation.

Are you writing a cross-platform app, i.e. one that is intended to run both on Android and on some or all of the desktop platforms?  In that case I could perhaps be persuaded that a dialogue box is a sensible choice.  But if it's an Android-specific app I would have thought something more tailored to a touchscreen interface, and more typical of other Android apps, would be better.

Richard.

Re: BBC BASIC for iOS?

Richard Russell
 

Playing with the iPhone (I realise it's rather like communing with the Devil!) has at least answered one question: what to do about the absence of the Android 'back' button.  Other apps which require that functionality, including Apple's own 'Settings' app, seem to have established a convention of providing a back button in the top-left corner (sometimes bottom-left, such as in Safari) consisting of a simple 'chevron' or less-than symbol.  It shouldn't be difficult for BBC BASIC to overlay a similar button; there will be occasions when it obscures something important but experimentally rotating the device from portrait to landscape usually moves it out of the way.

Richard.

Re: Testers wanted

Richard Russell
 

The deadline has now passed, and disappointingly there have been very few responses from the testers.  Indeed most of the people who requested a beta copy didn't even bother to acknowledge receipt.  I know I shouldn't be surprised, or allow it to upset me, but it always does.  :-(

The small number of reports received have, on the whole, been negative.  It seems that people have had much more difficulty getting the utility to work for them than I hoped.   The users concerned may (or may not!) wish to post their own reasons for not being enthusiastic.

The concept of a tool which would automatically convert a BBC BASIC program to a self-contained Android app seemed initially very exciting, but like so many of my 'grand ideas' it hasn't worked out.  Sorry.

Richard.

Re: Testers wanted

dai_m_leeds
 

Hi Richard,

I know it took a bit of headscratching to work out why I was struggling, but once we'd realised the program needs to sit in a directory path with no spaces, it was pretty straightforward after that. Now that I have my keystore and template working, presumably making more will be striaghtforward.

I am enthusiastic- please don't despair/give up: I think the prize is well worth the hassle..

Best wishes,

D

Re: Testers wanted

Paul Marshall
 

On Wed, Feb 28, 2018 at 03:35 pm, Richard Russell wrote:
Sorry.

Richard, you have nothing to be sorry about. As one of those who has been in communication with you let me state publicly that you've have created a superbly useful tool.
Yes  there were some difficulties, all centred around filenames. If these snags appeared to be negative it wasnt meant too, I regret that one simple error creates a chain of emails!

Now that we know the following it is not an issue any longer:

  • filenames must not start with a dot
  • filenames must not contain spaces
  • filenames are case sensitive

Some problems with  the package name have been resolved. It might put some people off if they think they need to have a website but it doesnt appear to matter what the company name is.

I have turned two programs into Android apps really without any other real problems. Admittedly they were old Acorn programs with nothing particularly clever and no Windows api calls, but it's good experience for the future. And - although you will criticise me for this - I didnt even test my latest program on the Android first. Such is the ease of compiling that I prefer to make changes in Windows SDL compile, install and test on the tablet. Thats because although TouchIDE is useful I am a dyed-in-the-wool Windows user and find it much easier.

I assume the 'string too long' is still an issue but if it works on the majority of devices and only fails on one or two I would beg you not to deny it to the rest of us.

Re: dlgdemo with keypad

Paul Marshall
 

I really like the simplicity of the Android touch interface. To build a Windows program with a nice UI that used menus, dialogue boxes etc was massively complicated even with the library functions. (parachute on, ready to be shot down)  With Android all that is needed is MOUSEX%,Y%,B%  kind of thing, compare where on the screen the user has clicked and you are on your way!

Re: Testers wanted

Richard Russell
 

The facts here are that two of the most experienced and most knowledgeable BBC BASIC users struggled so badly to get my utility working that they were both unable to without extensive help from me.  I can confidently say that most people would find it more difficult, not less, than they did.

I assume the 'string too long' is still an issue

I've left the 'workaround' code in place, so it should no longer affect the operation of the loader program (autorun.bbc) but it could still of course affect the operation of users' own programs if they are also using the $addr kind of 'fixed string'.

> I would beg you not to deny it to the rest of us.

I'll do a deal with you: if - despite the deadline having passed - I receive encouraging feedback from some of the others who offered to test it, but have not yet responded, I will reconsider my decision not to release it.  However given the lack of response and general apathy I do wonder whether the "rest of us" actually amounts to 'nobody'.

Please ensure that you have downloaded the latest version (0.32) which has some changes that should ameliorate a few of the problems encountered.

Richard.

Re: Testers wanted

Richard Russell
 

On Thu, Mar 1, 2018 at 01:48 am, Paul Marshall wrote:
it doesnt appear to matter what the company name is.
Of course it matters!  Did you not read the supplied help file, which I recommended that everybody study before trying to use the utility?  The package name must be 'globally unique'; if you don't have a domain and just 'make up' the name there is every likelihood the somebody else might have chosen the same name.  In that case if an end-user, who had previously installed the 'other' app, installed yours it would wipe out the original!

You can't even argue that you can change the name should such a situation come to light, since once allocated you can never change the package name(because it will break the 'app update' process whereby a newer version automatically replaces the older one).

If you haven't got a domain I strongly recommend that you obtain one; they are very cheap.  But even if you don't, you still have the option of (hopefully) guaranteeing uniqueness by using a 'reversed' email address as the initial part of the package name.

Releasing Android apps to the 'wide world' requires that you adopt a professional approach, just as releasing 'compiled' BB4W executables does.  Since all such EXEs and apps made using BBC2APK contain details that allow them to be traced back to me, it could reflect badly on me if you don't.

Re: Testers wanted

Paul Marshall
 

On Thu, Mar 1, 2018 at 02:05 am, Richard Russell wrote:
The facts here are that two of the most experienced and most knowledgeable BBC BASIC users struggled so badly to get my utility working that they were both unable to without extensive help from me.
Surely the idea of having feedback from testers was to iron out those difficulties so that others do not get stuck. Maybe two is enough.  We now know about filename restrictions - and you did tell us about leading dots, and case sensitivity was a silly error - but wont be an issue in future. A few things you have ameliorated in the latest version so it should be easier for any new adopters..
It is indeed very bad that so few have bothered to try it. So come on guys I dont want to lose this tool just because you cant be bothered!   

Re: Testers wanted

Richard Russell
 

On Thu, Mar 1, 2018 at 04:29 pm, Paul Marshall wrote:
I dont want to lose this tool just because you cant be bothered!   
I don't understand how you can "lose" what you've already got.  It's not as though the version currently available for download is a time-limited trial version, or restricted in some other way; it's fully functional and there's nothing to stop you continuing to use it.

Richard.

Re: BBC BASIC for iOS?

Richard Russell
 

On Tue, Feb 27, 2018 at 04:33 am, Richard Russell wrote:
I don't know of any workaround for SOCKLIB however.
This is proving to be less of a problem than I feared.  I've today experimented with allowing the 'read from network' function to block, and so long as I read relatively small packets - and have a relatively fast internet connection - the effect on the performance of 'banner.bbc' and 'Ceefax.bbc' is not too serious compared with the version of socklib using assembler code.

Richard.

Re: Testers wanted

mclout@...
 

I will be installing and working on this this weekend.  Just did not have time to get to it.  I too think this is a very valuable project and tool for the community. 

Re: dlgdemo with keypad

Ian_Wade_G3NRW
 

Richard

I had a hunch you might say something like this. It's coming home to me that my mindset for writing Android apps is quite inappropriate. Trouble is, I have spent a lot of time over the last 4-5 years getting to know BB4W well, and along the way learning a lot about the Windows API. And enjoying it.

I'm now realising that I need to approach the Android world quite differently, and it's time to go back to basics -- after all, my 11-year old grandson can stand his Android on its head with some very impressive apps! He must get the same kind of buzz that I used to experience when persuading machine code to work on very simple process control systems way back in the 1960s.

--
Ian

On 28/02/2018 14:42, Richard Russell wrote:
As I said before, dialogue boxes are largely foreign to Android; I don't think I've seen a single Android app with what could be described as a conventional dialogue box as part of its UI.  For that reason it would probably have been better if I had omitted dlgdemo.bbc from the Android edition; it's there because it's included with all the 'desktop' editions and I forgot to remove it, for want of a better explanation.
Are you writing a cross-platform app, i.e. one that is intended to run both on Android and on some or all of the desktop platforms?  In that case I could perhaps be persuaded that a dialogue box is a sensible choice.  But if it's an Android-specific app I would have thought something more tailored to a touchscreen interface, and more typical of other Android apps, would be better.
Richard.

Re: Testers wanted

Richard Russell
 

On Thu, Mar 1, 2018 at 04:29 pm, Paul Marshall wrote:
Surely the idea of having feedback from testers was to iron out those difficulties so that others do not get stuck
Of course that's true to a degree, and to be fair I think the problems you had have largely been ameliorated by adding warnings to the program.  But the other person who provided feedback had much more difficulty than you did, even to the extent of not understanding how the Embedded Files feature works (despite it working in an identical fashion to BB4W, and even presenting an identical UI).  I really worry that if somebody so experienced struggled with it, releasing it to the 'wide world' would be unwise.

Perhaps (and of course I'm joking, but it's tempting!!) the program, when first run, should present the user with a multiple-choice questionnaire to assess his level of knowledge.  It could ask questions like 'What does the REM!Fast compiler directive do, and when mustn't you use it?".  That would sort the wheat from the chaff!  :-)

Richard.

Re: dlgdemo with keypad

Richard Russell
 

On Fri, Mar 2, 2018 at 12:04 am, Ian_Wade_G3NRW wrote:
I had a hunch you might say something like this. It's coming home to me that my mindset for writing Android apps is quite inappropriate.
The last thing I want to be is discouraging, but on the other hand it's better to nip bad habits in the bud before they get too ingrained.  There's nothing special about Android's typical user interface, indeed it's just the same as you might get in a Windows video game.  Take for example 'Dibley' or 'Dropperz' or 'Forces of Darkness'; they are all games written initially for a desktop platform, yet when the user is asked to select options (maybe to enter his name, or enable or disable sound) he isn't presented with a 'dialogue box' but with a bold, colourful screen with chunky buttons.  The functionality is the same, but the UI suits the 'look and feel' of the rest of the program.

By the nature of having to interface with them using a small touchscreen, virtually all Android apps - whether they be games or online banking apps - present a similar style of interface: highly graphical, simple to operate even with 'fat fingers' or when wearing gloves, perhaps with audible feedback.  As Paul pointed out, this is easy to do in BBC BASIC, indeed it's the sort of interface a BBC Micro program might have presented 35 years ago!   Dialogue boxes have their place, but it's principally in desktop applications which are primarily keyboard-and-mouse driven and where the rest of the program is using a similar 'formal' style of interface.

Richard.

Re: BBC BASIC for iOS?

Storer, Darren
 

Hi Richard,

Just a quick thought about the iOS back button challenge... Some of the apps that I use implement an Android style back button functionality by using the "undo" feature that was introduced a few years ago. If you are entering text into an application such as iMessage, and you make a mistake, you can "undo" the input by shaking the iPhone from left to right rapidly.

You can disable the iOS undo function (accessibility settings) but it is enabled by default.

Currently I am snowbound in Edinburgh, without an Android phone to test the APK routine (my mistake) but I have a couple of iOS devices with me if you need any testing.

Hope this helps

Darren

On 28 February 2018 at 23:15, Richard Russell <news@...> wrote:
Playing with the iPhone (I realise it's rather like communing with the Devil!) has at least answered one question: what to do about the absence of the Android 'back' button.  Other apps which require that functionality, including Apple's own 'Settings' app, seem to have established a convention of providing a back button in the top-left corner (sometimes bottom-left, such as in Safari) consisting of a simple 'chevron' or less-than symbol.  It shouldn't be difficult for BBC BASIC to overlay a similar button; there will be occasions when it obscures something important but experimentally rotating the device from portrait to landscape usually moves it out of the way.

Richard.


Re: dlgdemo with keypad

Ian_Wade_G3NRW
 

Message understood. Don't worry, you are not discouraging me at all. Just the opposite. Your "re-orientation" comments are most useful.

--
Ian

On 02/03/2018 09:50, Richard Russell wrote:
On Fri, Mar 2, 2018 at 12:04 am, Ian_Wade_G3NRW wrote:
I had a hunch you might say something like this. It's coming home to
me that my mindset for writing Android apps is quite inappropriate.
The last thing I want to be is discouraging, but on the other hand it's better to nip bad habits in the bud before they get too ingrained. There's nothing special about Android's typical user interface, indeed it's just the same as you might get in a Windows video game.  Take for example 'Dibley' or 'Dropperz' or 'Forces of Darkness'; they are all games written initially for a desktop platform, yet when the user is asked to select options (maybe to enter his name, or enable or disable sound) he isn't presented with a 'dialogue box' but with a bold, colourful screen with chunky buttons.  The functionality is the same, but the UI suits the 'look and feel' of the rest of the program.
By the nature of having to interface with them using a small touchscreen, virtually all Android apps - whether they be games or online banking apps - present a similar style of interface: highly graphical, simple to operate even with 'fat fingers' or when wearing gloves, perhaps with audible feedback.  As Paul pointed out, this is easy to do in BBC BASIC, indeed it's the sort of interface a BBC Micro program might have presented 35 years ago!   Dialogue boxes have their place, but it's principally in desktop applications which are primarily keyboard-and-mouse driven and where the rest of the program is using a similar 'formal' style of interface.
Richard.