iOS / iPadOS version

[glyph]

You can't use it like the desktop version, the APIs don't exist to do that, but maybe you could display the timer fullscreen and disable sleep, for folks working on computers where they can't install software

[glyph]

Maybe I could do this with pythonista?

[glyph]

Maybe I could do this with pythonista?

Pythonista has gone without an update since Python 3.5, so I think this is probably a non-starter.

[glyph]

What's up @freakboy3742

[freakboy3742]

@glyph You rang? :-)

Displaying a timer full screen should be fairly straightforward. Toga doesn't have a cross-platform API to disable sleep, but you can access the native API layer without too much difficulty (and I wouldn't be opposed to adding a cross-platform API to expose that functionality).

Beyond that, I'd need to know more about the UI mockup to give advice - but I'm happy to give pointers.

[glyph]

@freakboy3742 This was more of a general ping, like "how should I go about this". Is there something I could stick in a setup.py to get started quickly? I don't mind slogging through API docs in order to achieve specific things, but getting an initial build to work (particularly "what the heck do I do for CI") is the part which is hard to get motivated to get through

[freakboy3742]

@glyph If you run the beeware tutorial, you'll get a GUI going; from there (combined with poking around the API docs and examples - especially the handler example, I suspect) you should be able to get something going.

CI is a bit of a hairy story at present. We've got an open ticket to document our CI story (beeware/briefcase#400), but there's two big problems that really need to be resolved first:

1. Running tests for a GUI app
2. Signing/App Store submission

Testing GUI apps is A Hard Problem (tm) no matter the platform, and Toga doesn't have a great story for these at present (it's very much on our todo list). The theory is that you should be able to use the "dummy" Toga backend - a full implementation of the Toga internal API that doesn't have any actual GUI manifestation, but exposes APIs that can be manipulated in by a test. The idea is that the Dummy API is the "API ideal", and all the platform backends are tested to confirm that they do the same thing as at the Dummy API - so your end-user app should only need to do a high-level test to confirm that the platform backend is working.

App Store submission is something that isn't currently automated; I'm not even sure if it can be fully automated. Even getting app signing and notarization automated is problematic.

However, if you just want to get a build out of the CI, you can invoke briefcase build in CI - the Briefcase repo does this in its own CI to confirm that apps compile on all platforms and backends.

[glyph]

@glyph If you run the beeware tutorial, you'll get a GUI going; from there (combined with poking around the API docs and examples - especially the handler example, I suspect) you should be able to get something going.

OK, I'll have to run through that when I start getting around to iOS stuff.

CI is a bit of a hairy story at present. We've got an open ticket to document our CI story (beeware/briefcase#400), but there's two big problems that really need to be resolved first:

1. Running tests for a GUI app
2. Signing/App Store submission

Testing GUI apps is A Hard Problem (tm) no matter the platform, and Toga doesn't have a great story for these at present (it's very much on our todo list). The theory is that you should be able to use the "dummy" Toga backend - a full implementation of the Toga internal API that doesn't have any actual GUI manifestation, but exposes APIs that can be manipulated in by a test. The idea is that the Dummy API is the "API ideal", and all the platform backends are tested to confirm that they do the same thing as at the Dummy API - so your end-user app should only need to do a high-level test to confirm that the platform backend is working.

I appreciate what you're trying to do here, but I would probably want the ability to at least limp along in CI with a simulator, both to make sure the build infrastructure actually works all the way, and also to test things like interfacing with platform-native facilities which don't have a Toga equivalent (sensors, notifications, and so on).

App Store submission is something that isn't currently automated; I'm not even sure if it can be fully automated. Even getting app signing and notarization automated is problematic.

There are nominally some github actions for this that work "out of the box" on vanilla Xcode projects, but I've had to build my own shell script from scratch even for the Mac versions of this.

However, if you just want to get a build out of the CI, you can invoke briefcase build in CI - the Briefcase repo does this in its own CI to confirm that apps compile on all platforms and backends.

If I did get such a build out of CI (I'm assuming "an unsigned .ipa file"?), would you happen to know enough about the iOS dev workflow to know where I'd put it or what I'd do with it? Xcode seems to get very confused when you want to do stuff with something that isn't "an Xcode project in Swift getting pushed to a real live device", and while I know enough about the innards of what's going on on the Mac in order to get the various command line tools to Do A Thing, I don't know what the equivalent looks like on iOS.

[freakboy3742]

Testing GUI apps is A Hard Problem (tm) no matter the platform, and Toga doesn't have a great story for these at present (it's very much on our todo list). The theory is that you should be able to use the "dummy" Toga backend - a full implementation of the Toga internal API that doesn't have any actual GUI manifestation, but exposes APIs that can be manipulated in by a test. The idea is that the Dummy API is the "API ideal", and all the platform backends are tested to confirm that they do the same thing as at the Dummy API - so your end-user app should only need to do a high-level test to confirm that the platform backend is working.

I appreciate what you're trying to do here, but I would probably want the ability to at least limp along in CI with a simulator, both to make sure the build infrastructure actually works all the way, and also to test things like interfacing with platform-native facilities which don't have a Toga equivalent (sensors, notifications, and so on).

Oh absolutely - no disagreement on that. Working out how to get this to work - if only for Toga's own CI - is definitely on my todo list.

App Store submission is something that isn't currently automated; I'm not even sure if it can be fully automated. Even getting app signing and notarization automated is problematic.

There are nominally some github actions for this that work "out of the box" on vanilla Xcode projects, but I've had to build my own shell script from scratch even for the Mac versions of this.

Interesting... I will need to look into these some more. The good news from Toga's perspective is that the macOS and iOS apps are Xcode projects - so we may be able to leverage these directly.

However, if you just want to get a build out of the CI, you can invoke briefcase build in CI - the Briefcase repo does this in its own CI to confirm that apps compile on all platforms and backends.

If I did get such a build out of CI (I'm assuming "an unsigned .ipa file"?), would you happen to know enough about the iOS dev workflow to know where I'd put it or what I'd do with it? Xcode seems to get very confused when you want to do stuff with something that isn't "an Xcode project in Swift getting pushed to a real live device", and while I know enough about the innards of what's going on on the Mac in order to get the various command line tools to Do A Thing, I don't know what the equivalent looks like on iOS.

At a high level, that's pretty much it - you get a .ipa file, which then needs to be signed, archived and sent to the App Store. The "vanilla" tools to do this through Xcode are all GUI based, though - I have no idea if there are command line equivalents. I suspect there are... but like all Apple stuff, the command-line equivalents are not well advertised.

[glyph]

At a high level, that's pretty much it - you get a .ipa file, which then needs to be signed, archived and sent to the App Store. The "vanilla" tools to do this through Xcode are all GUI based, though - I have no idea if there are command line equivalents. I suspect there are... but like all Apple stuff, the command-line equivalents are not well advertised.

There are definitely command-line equivalents, what you want to look at are the man pages for man codesign (invoked as "codesign") and man altool (invoked as "xcrun altool"). But of course they have a million fiddly options and no "test mode" (you're going live to some testflight or app store listing if you run them) so I am not really clear on how you use them because you need a full-fledged app to try.

[glyph]

While looking at the docs for this though I found https://docs.fastlane.tools which probably has some interesting ideas to at least crib from, if not to just use outright