[android] ImageView, NOT merged: How to staple & click them (MahJong solitaire)

[clemsam]

Hi, I used pygame's Pong Snake Game example successfully with briefcase but know (from a Russell comment) that modules containing binaries will not work in mobile development (unless cross platform themselves).

So I can't take pygame for my (written in java) android Mahjong solitaire app.
I really want to only use cross platform tools -- no "import android" for me!

I know I can "transcript" the game's logic to python (done it in javasript) but it is crucial to have several "layers" of images/sprites/ buttons overlapping (often hiding) the ones underneath; "layer" here is meant in a graphical sense = drawn one above the other (no "real" layering needed, no animation etc.).

Are there any known ways to achieve such a "pseudo layering" with toga ?

[Edit:] as I found out, principally YES: ...style.update(padding_top= -400, [...] ) but affects other boxes/image(view)s & must be compensated for.

(All game examples I found used buttons next to each other, like chess fields, never overlapping...)
... or can selected modules of e.g. kivy be imported parallel to toga with any hope of success? (If so, how?)
If nothing else works, could a web view help me somehow? ... or are there plans for the (near) future to implement any bitmap/sprite handling capabilities for toga?

I'd be gratefull for any helping hint or link to working examples!
Stay all healthy! clemsam
.
.
Here's a screenshot of my javascript transcript (w/o colours, shadows etc.) from toga's WebView example ...
(btw: anybody know how to load local html files to emulator? url='file:///Users/myName/MahJong/HTML.html', does not work...)

[freakboy3742]

There's a bunch of questions/themes here; I'll do my best to address them all.

The ability to deploy PyGame on mobile has more to do with PyGame than briefcase. PyGame involves tight integration with system libraries; you can't just deploy macOS PyGame on Android. If someone were to port PyGame to Android/iOS, Briefcase should be able to deploy it - but that port won't be a simple task.

Briefcase layouts aren't really focussed on "game" style layouts, so overlaying buttons isn't something that is well catered for. The closest thing I can think of would be to use a Canvas view; you can lay out arbitrary shapes on a canvas, and there is also click events, so you could probably mash that together into a responsive interface. However, there isn't any support for bitmaps on a canvas - only vector drawing.

A web view may also be an option; web view has already been implemented cross platform. However, at that point you're not really developing a cross platform native app - you're developing a webpage with delusions of grandeur :-) However, it is an option.

There is a BeeWare-related project called Yorkshire4 that includes a bitmap view; it was only implemented for Cocoa and GTK, and there's almost certainly been some bit-rot over the years - but it might be a starting point if you're interested in exploring that option.

[clemsam]

Thnx a lot for your overnight (for me) answer to my question. It more or less is what I was afraid it would be. I've stumbled upon attempts like here: kivy/kivy#6999 to use briefcase to bring kivy code to android; but I feel that toga is the soul of BeeWare, briefcase just a clever and handy tool...
I never thought that pyGame code could be translated to Android, so I'll have a look into this Yorkshire4 project (will take a few days) and come back here.
(My goals in this are to practise "universal" python, to get my outdated MahJong game onto a modern OS tablet & to eventually try a "port" to iOS as well; and I'm fantasizing about doing a Carcassonne-like clone)

[clemsam]

Something new has come up / to my attention:
In Discussions [android] image button.on_press() possible? #1343 you (freakboy3742) mentioned PR #1213.
That one led me to a page #1213 Imageview on_press event / Compare that describes/implements a way to add an "on_press"
function to ImageView that is shown in an example imageview.py file.
I used this as template to adapt my game idea from above's screenshot (MahJong) and so far succeeded in actually "stapling" some tiles in a similar way. Like this:

These 5 different "staples" above consist of a Box() each, filled with ImageViews that contain one image.
These are taken and looped from a list (of integers from 1 to 40) and are "aligned" by padding_left=XX*i, padding_top=XX*k.

I encountered the problem that eval() in python will only allow me to use the integers as part of names (e.g. eval("img_"+str(i)+".png") ) for an image img27.png) but not in a "looped" assignment like eval("imV_"+strg(i)) = toga.ImageView ( eval("img_"+str(i)) ) – in Java and JavaScript leading to imV_27 = toga.ImageView (toga.image('resources/img27.png')).
(So right now I had to write a one-liner for each assignment.)

Furthermore the appended function (?) on_press=self.on_image_click is not (yet) meant to accept an argument to "know" which one ImageView (rather: image) has sent the on_press message. … which I need to decide if two clicked tiles display the same image (resulting in their removement).

I am working on solutions but that will take some time (I'm a hobbyist,as mentioned before).

[freakboy3742]

#1213 - As fair warning; while that PR has been proposed, I'm highly sceptical about including it. It encourages a type of UI that I'm trying to discourage; the discussion thread you've linked covers the philosophical argument.

I'll also repeat my previous advice that Toga isn't well set up for "games" type development. It's aimed at building native UIs using native UX elements, and games generally don't follow "native" UI patterns.

As an aside: If you're using eval()... you're doing it wrong. eval() is a dangerous tool, and unless you're doing very low level interpreter manipulation, it's almost never required.

From the examples you're providing here, not one of them requires the use of eval; and most of them don't require the use of str(). `toga.ImageView(f"img_{i}") will do exactly the same thing as your eval+str constructions.

[clemsam]

Again – thnx a lot for your immediate reply!
As I proved here several times I'm an amateur "programmer" (obviously), doing this just for fun...

It seems to me that you really want to discourage me from doing my "game thing" at all with toga –?!?
I'm quite clear that you possibly will never include this PR. Does this mean that my game would not work (= run) on non-local computers or smartphones (IF I can finish it)?

And why are you opposed to have (even such simplistic) games written ("translated") with the beeware suite, when I can find highly praised examples of tic-tac-toe and similar ones on the net (even at github)?
(This is meant as a real question – NOT to provoke or critisize anyone or any philosophy…)

I am most grateful for your aside and the hint to use toga.ImageView(f"img_{i}").
(Why didn't I find this solution when googleing my problem? ... probably: never learned to ask the right question.)

I wish you a nice day/evening/night – dependent on where you are located. Thanks again for your hint !!!

[freakboy3742]

To be clear - I'm not opposed to the concept of writing games with Beeware; I'm just saying that the tools that are there right now are not a good match - and if you're a novice/amateur programming, you're going to be fighting the tools all the way if you want to build a game in Toga.

Tic Tac Toe et al are "toy" games. They're good example apps because they contain simple business logic, a problem space that people understand, and very modest UI needs. However, if you push much beyond that, you're going to hit the limits of Toga as a game writing platform.

In the fullness of time, Toga may become a more plausible solution for games programming. However, the needs of game programming are very distinct from the needs of "app" programming, and it's possible the two may not be able to be reconciled.

The corollary: if you wanted to build a Excel-like business app, PyGame probably isn't the right choice, either. You might be able to cobble something together with PyGame, but you're going to have a much easier time using Toga. And asking the PyGame team to add features to make it easier to have an Excel-like data grid feature would be laughed out of the room - that's not what PyGame is for.

It's certainly possible that in the fullness of time, Toga will acquire features that make it useful for games programming. However, I think it is much more likely that another games-oriented framework (like PyGame, or PursuedPyBear) will become well integrated with Briefcase and the BeeWare deployment tooling, and become a viable tool for games programming on mobile.

[clemsam]

I think the main reason why I like BeeWare is the "Write once ..." motto. Programming is fun (more demanding than cross word puzzles ;-); I recently discovered python while searching for ways to make AppleScript mouse-event-aware (pynput).

I started out in the early 2000s on my eBook reader (Sony-PR ... 16 shades of grey); somebody there developed a Sudoku game in a js-similar language. This inspired me to do my lightblue MahJong, later in "real" javascript (above).
As my family both use iPads I'd also like to have my MahJong put to iOS w/o having to learn Swift on top.

So: BeeWare delivers all the infrastructure I need for all platforms I aim at -- with only "Writing Once".

(btw: I 1st computed on a Mac-Apple-II for a European research institute in 1989, later doing 6 yrs of MicroGrafx/Powerpoint presentations for Anderson Consulting (first) on a Windows runtime (? 1.2 ?); the fun was making Ppt do things it was never meant to do...)

[clemsam]

Here are some new developments:

(Above: 2 screenshots –partly overlaying– from briefcase's android_sdk Android emulator.)

Each of the above Mahjong tiles is defined (for now) like this:

  iView1c = toga.ImageView(toga.Image('resources/m12.png'), on_press=self.on_image_click)
  iView1c.style.update(height=70, width=70, padding_left= -10)
  self.box1.add(iView1c)

  # "padding_left= -10" achieves a slight overlap (≈ 3D-like)

– There will be 9 boxes (stapled in a COLUMN Box): self.box1 ... self.box9 ***
– Each box is a ROW of max 8 tiles left-to-right (usually: 7)
– Each box is up to 7 tiles "high" thus containing a max of 56 tiles (never happens...)
– All 9 boxes together could hold up to 504 tiles, but actually about 140 is my max (see screenshot, right side)

Toga's import Pack is a serious limitation to placing objects (views) at specific positions as it tries to "squeeze" ImageViews-in-boxes-in-boxes...
I had to find a way to get around this:
My solution is to create an invisible (and unused/unchanged) "anchor" for each ROW (= box) at its zero position (so the box's height will be stable) and to use absolute values for widthand heightfrom there on.

I tried to work with .insertand .removeto get rid of double-tiles (inserting "invisible" tiles instead) but that didn't translate to briefcase run android -u. Bad luck!

I was near to giving up when I thought of instead bringing a tile's width to zero: on_image_click(self, widget): widget.style.update.(width= 0).
Actually that works quite fine but leads to some funny side effects (like sending tiles some pix to top or left … argh!).

In my 10 years old version I could just use an onClick_listener from Java to get real XY-positions but Toga's Pack won't do this...
I'll have to make each "clickable" imageView tell me its own position relative to neighbours.

So right now "deleting" individual tiles from this "outer_box" works fine w/o disturbing the general layout.
I will have to make a "parallel" structure for each design ("Dragon", "Pyramid", "Castle", ...) that contains status for each tile and is updated when tiles are "eliminated" (as doublettes) as I cannot "remove" them completely.

(I hope to find some progress mid next week.)
.

.
*** (Just a background info: my layout's origin (9*8) is an ancient eBook reader that had 10 hardware buttons on its bottom of which I used the middle 8 ones for selecting the column plus Page Up and Down buttons to move vertically. Thus I could not make the tiles overlap halfways, either.)

[clemsam]

NOT a reply but an UPDATE:

X_Go_Android.mp4

I made (and heavily edited) this little video with MacOS' emulator function Screen record but had to insert the HAND cursor myself (via Preview).

The game runs rather slowly in the onscreen emulator but takes <3 sec on my tablet for its own startup screen (= "Glyphe" design) while a delay to "remove" touched/clicked tiles is hardly noticeable (tablet screen: 1920x1200 pix; cpu: MediaTek MT8183, armeabi-v7a; Android vers. 9, amazon-customized).

[clemsam]

BTW: is my "discussion" rightly placed here at "Discussions" or should it be moved somewhere else -- is it actually considered acceptable by maintainers? ... or should I "emigrate" to e.g. Stackoverflow ?!?

.
Right now I wonder, is there a way to make ImageViews return an "iterable" information about their relative position inside a box, like: widget.parent.getPos(self) -- ?

Furthermore I will try to make the background either colored or display an image.
Does anybody have realworld-proven experience with Android => briefcase coloring?
[Question above: Solution hinted by HKLM, then found by me and appended to HKLM's reply, below.]

Appending shadows to tiles is routine, will be finished next;
comparing pics of 2 tiles additionally needs exclusion of left-AND-right-neighbours (otherwise takes a dict to hold infos);
the game's logic consists of quadrupels of pics, therefor 3-twins-in-1-staple must be eliminated (elif: unsolvable);
1-step-undo is nice-to-have, too.

Well, thanks for comments on above issues in advance!
.
.
P.s.: anybody have experience with edittig/adding information directly in/to android-java/xml code (generated by briefcase run android), and exactly where would I have to edit?
[Answered: below HKLM's reply ...]

[HKLM]

Well, thanks for comments on above issues in advance! . . P.s.: anybody have experience with edittig/adding information directly in/to android-java/xml code (generated by briefcase run android), and exactly where would I have to edit?

Look in your <YourProject>\android\gradle\<YourProjectName>\app\src\main folder. There is the AndroidManifest.xml there... Im not sure what you want to do...

I do agree with freakboy3742 that toga is probably not ideal to make your game with. Sure it can be done, but you can also cut down a tree with a butter knife. While it is possible, there are better ways.
For example, have you looked in to using the Unreal Engine? It has been used to make everything from 3D FPS games, to 2D games, and even used to make professional movies. You can get the complete source code and all the tools to make games from Epic for free. The only catch is, if you release your game for sale, to the public, you have to pay Epic. I think its 5% of each sale, for royalties. ($0.05 for each US dollar not a bad deal at all)

I just found out that it supports Python! https://docs.unrealengine.com/4.27/en-US/PythonAPI/

Here is some one else who is using the UE to make a MahJongg game https://forums.unrealengine.com/t/building-a-very-basic-mahjong-for-a-very-special-person/149064/26

[clemsam]

(Very belatedly:) Hi HKLM – thanks for your hint!

I added one line android:screenOrientation="portrait" under <activity …> in AndroidManifest.xml, so my app will only startup in its stable°° portrait orientation. (Background right now not crucial, will research later…)

I previously had changed the (MacOS AndroidStudio) emulator's resolution from (I think: default) 180 to 240 hw.lcd.density at ~/.android/avd/beePhone.avd/hardware-qemu.ini and ~/…/config.ini, so the emulator's MacOS onscreen display is similar to my 10"-tablet's.
(This sadly makes any message output very small/hardly readable with MacOS' emulator but is fine on the physical device.)
.
.
°° stable as Toga's Package squeezes ImageViews into a box and renders the right-most/lowest Imageview(s) either tiny or pushed outside the display (= invisible) – IF orientation is allowed to switch by tipping the device over.

[clemsam]

Well, "android:windowBackground" can be changed (from default white) in src/main/res/values/styles.xmlby adding e.g. <item name="android:windowBackground">@color/activityBackground</item> which then must be defined in src/main/res/values/colors.xml as e.g. <color name="activityBackground">#caffaa</color> giving backgrounds a light greenish tint from now on …

[clemsam]

NOT really new, but a (maybe last) screenshot of my Go_Android app, taken by a real world device…

I added the "risen tile" feature – otherwise the top and bottom lane of my "Castle" design would be nearly unresolvable.
Plus: shadows, but didn't bother to refrain them from showing (illogically) with "risen tiles".

Recognizing "pairs" working well now, placing a "marker" around selected tiles is hard with toga.Pack; won't implement "Undo" but probably switching between designs programmatically and placing background image; as mentioned before will try to develop a kind of Carcassonne clone next – graphics are ready so far…

[clemsam]

Just a practical hint/notice; I don't think this justifies a full new Discussion:

When using an emulator with different resolutions/densities (for tests on several real world devices) I had some difficulties in re-setting to my "native" screen resolution; I found an ingenious hint at stackoverflow, telling me to write in Terminal:

adb shell wm density 240 [or any other resolution ≥72 you may need]

[clemsam]

Here again ...
Right end: total screenshot from an Amazon-Fire-HD10 / to the left: 100%-part of start screen with system dialog / middle: three 100%-"cuts" with center one: blue clicked-on tile.
.

(Click image to open new tab with 100% display in your browser.)