implementation of a screen idle timer functionality

[jens-maus]

implemented a screen idle timer functionality where the main screen is automatically dimmed and a separate black screen view is overlaid over all existing views. This should allow to set an idle timer (in the setup) so that the browser is automatically set blank if no further gesture/touch has been performed for a certain amount of time. In the end this should mimic a kind of screensaver/blanker required if the browser is used in environment where it might be running over a longer period of time but should keep its connection to the webpage currently displayed/loaded.

[jens-maus]

Please note that I just added a basic motion detection functionality to this pull request which uses the GPUImage framework to detect motion in front of an iOS device using an existing video camera. If motion is detected the screen saver exits accordingly.

[stakes]

OK - this motion detection is WAY COOL.

Are you using Frameless as a platform for a kiosk-style web app? What do you think about having a separate branch of Frameless for kiosk app developers to use where kiosk-specific functionality can live?

I'm curious because I am considering stripping down Frameless to just the bare-bones, even moving Framer.js-specific functionality to another app entirely.

[jens-maus]

Yes, indeed I am using Frameless as a kiosk browser app here in my environment. In fact, I am using a home automation system hear and I have an iPad located at the entrance of my house. This iPad is loading and keeping up a connection to my home automation system and displays content and allows to set several parameters as well using this interface. As a matter of fact I recently stumbled over Frameless and enjoyed its speed and lightweight design and chose it for the appropriate app for this. However, it was missing some of the features to use it in this type of environment (e.g. start page loading, screen idle timer and the fancy motion detection using the front camera so that it comes back from screen saver mode immediately. – btw, currently working on audio recognition to identify noise and bring the browser back from screen saver mode as well :)

Regarding separating development I also thought about what might be potential possibilities. One could indeed be, that we put all my changes into a separate branch within the Frameless repository. However, how should this then end up one day in the iOS App Store because I really want to push my changes to public so that others using the same home automation system can use it as well? Another possibility would be to rename my fork and keep it almost independent from your development, but I don't know if this would be the better option in long term since you might add some other functionality/fixes I want to import into my fork as well. The question really is how much you have planned to strip down Frameless and what the main motivation behind that is?

In addition, I have also planned to look into possibilities to add some features to let Frameless directly communicate with that home automation system via a public XMLRPC API this system provides. This would greatly enhance functionality and possibilities to interact with that kind of Kiosk browser.

So what do you think we should do with all my changes and how we can push that out to the public?

[stakes]

Wow, you have some seriously great plans for this.

The notion of stripping down Frameless comes from a few places. I initially built the app as a companion for Framer.js prototyping, but there are a lot more use cases than that (like yours!) that I've heard about in practice. At the same time, there's an opportunity to go deeper on the Framer use case (see: https://github.com/stakes/Frameless/pull/34) as well as the eventuality that the Framer team will release and maintain their own version of an iOS companion app like they have with Android.

I think at that point it'd make sense to pull back and focus on getting basic browser building blocks right (like https://github.com/stakes/Frameless/issues/24) and adding functionality that allows a better browsing experience (like https://github.com/stakes/Frameless/issues/22) than going deep on different, nuanced use cases, whether that is Framer prototyping or kiosk app development.

Personally I think that maintaining your separate fork of Frameless is the move. If you want to collaborate on releasing to the App Store I'd love to help with that. We could come up with a name/branding/positioning that matches your use case. Seems like fun.

Also, what home automation system are you using, by the way?

[stakes]

OK @jens-maus - I've got an update on this. I'm taking back much of what I said in the above comment about the future of Frameless.

I'm going to keep Frameless focused on a primary use case of helping Framer Studio users prototype effectively. I'm going to just merge the updates (sans cosmetic/branding changes) in this PR into the master branch and ship them to the app store soon:

https://github.com/stakes/Frameless/pull/34

And I'm also going to pull in PRs that either enhance that primary use case or support a secondary use case for Frameless as a basic web browser and don't add too much additional complexity. Those are your PRs:

https://github.com/stakes/Frameless/pull/42 https://github.com/stakes/Frameless/pull/41

This PR for screen timer/motion detection that we're chatting about is cool as hell. And like all of your PR's it's tremendously appreciated! But this one adds a feature that doesn't necessarily enhance the primary use case as a companion to Framer Studio. So I want to encourage you to maintain your own branch of Frameless that contains these kiosk-specific features and if you want to chat about getting it into the App Store somehow together and differentiating it I'd be happy to help!

[stakes]

Hey @jens-maus - just wanted to let you know that this contribution is now live in the App Store version of Frameless :+1: Thanks!