It's so hard to write example applications
-
Push the button and it disappears. Then two more buttons appear...
- I would love to change the world, but they won’t give me the source code.
-
When trying to illustrate by example my super-duper library, I found that in addition to this being surprisingly difficult, also that (1) parts of my interface were illogical and (2) a huge chunk of functionality was missing. So, I had to go back to the workbench and code. Six months later I found it a lot easier to write the examples and instructions. It seems that test-first gives your code one kind of perfection, while explain-at-last will take your code to yet another level. Thus the two cycles, test-code and explain-code, seems to complement each other.
In a subsequent post I wrote something similar. :laugh:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'm writing some examples for using my UIX library. It's unexpectedly challenging. I've created real world apps using it in less time than this. The difficult bit is making it not feel too contrived while at the same time making the code simple enough to understand. It's not writing simple code that's difficult, it's coming up with a simple application, that's nevertheless complicated enough to illustrate core concepts. It's so much easier when I have a direct purpose to my application, rather than dealing in the meta and writing it for its own sake. It makes me feel rudderless. Like, what is it even supposed to do other than exist? :confused:
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I always start with relational tables Alpha, Beta, Choice, Photo, and User. Beta has a foreign key to Alpha, Photo has a foreign key to Beta, Choice is for DDLs in either Alpha or Beta, All tables have foreign keys to User. Then let creativity flow.
-
David O'Neil wrote:
If you have a text input
The device I'm targeting for the example has no keyboard, no USB input, and a 320x240 touchscreen. I admit I chuckled at the thought. :-D I finally figured it out. It just took a lot longer than the code would suggest.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
The device I'm targeting for the example has no keyboard, no USB input, and a 320x240 touchscreen
So, if it's a common user control library you're trying to demonstrate (sorry if I've misread the thread), then David's idea makes a lot of sense, draw a control, attach a simple Hello World callback, just to demonstrate how to respond to it being used, and have a Next button to move to the page which shows another control. If it's all touch, with no room to display a virtual keyboard...then it all depends on what sort of user input the control is supposed to provide. But having your sample code show how to (a) draw the control and (b) respond to events that it raises, should pretty much cover it, IMO. An app that shows controls for the sake of showing controls sometimes *is* exactly what you need, as opposed to a real-world app that attempts to solve real-world problems. At least that would be my expectation.
-
Won't be any text editors or font editors on these, as they usually have 320x240 or smaller screens, no keyboards, and kilobytes of RAM. :) That said, I will consider your suggestions in light of that. Thank you.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
they usually have 320x240 or smaller screens, no keyboards, and kilobytes of RAM
I cut my teeth on the Commodore 64, which had 320x200, less usable memory, and no touch screen. I'm sure you could get "inspired" by looking at retro software.
-
honey the codewitch wrote:
they usually have 320x240 or smaller screens, no keyboards, and kilobytes of RAM
I cut my teeth on the Commodore 64, which had 320x200, less usable memory, and no touch screen. I'm sure you could get "inspired" by looking at retro software.
-
honey the codewitch wrote:
they usually have 320x240 or smaller screens, no keyboards, and kilobytes of RAM
I cut my teeth on the Commodore 64, which had 320x200, less usable memory, and no touch screen. I'm sure you could get "inspired" by looking at retro software.
It had a keyboard. But yeah.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I always start with relational tables Alpha, Beta, Choice, Photo, and User. Beta has a foreign key to Alpha, Photo has a foreign key to Beta, Choice is for DDLs in either Alpha or Beta, All tables have foreign keys to User. Then let creativity flow.
No database in this mess :) I'm dealing in kilobytes of ram and very small touch screens.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix