I wanted to develop my own watchface for my Gear S2. I found some good documentation on downloading and using the Tizen IDE. All is well, but I'm finding the tweak css/html5-run/upload-switch faces-view-wash-rinse-repeat to be very tedious and time-consuming.
I know I can point my browser (Chrome) to my development workspace and load the index.html up and I surmise that I could tweak what I have, which came from the template to work in the browser if I made the sizes in the css static vs dynamic (absolute vs percentages). But is there a better way? Scouring the Internets Googles have yielded nothing too helpful yet.
moderators: this might be OT for this particular SO. If that's the case, I apologize. A nudge in the right direction would be greatly appreciated, if so.
So, I was able to make a little progress on this myself. I am using Chrome in developer mode, which almost works perfectly when using the developer device emulator. To toggle the device emulator, open developer mode (windows: ctrl+shift+I, OS X: cmd+option+i) and when the tool window opens up, look for the little device button next to the element button in the upper left corner of the developer tools window. When the device emulator open, switch the resolution to 320x320 (top of the window next to "screen").
Now, open your index.html file for your project in Chrome, and you can at least muck around with your css styling.
Now to get around the whole issue of reloading your clock with the default clock in the Java emulator for Tizen, I was able to get my changes to automatically assert when running the new code. The way I did it, though I'm not sure if all of these steps were necessary was:
In the emulated watch:
1. set the screen timeout to 15 mins.
2. set the watch face to your development watch face
In the IDE:
1. when ready, use the button for smart launch (it's the blue button just to the left of the bug button in the tizen web IDE). This is in the Tizen SDK version 2.3.1 build 20150721-1440.
At the time of running your code -- making sure both your emulated watch is running too:
1. In the IDE, click the smart launch button
2. Click over to your emulated watch and make sure it's in focus.
It should update the watch face with your latest changes in realtime. This worked for me, so YMMV, but at least I didn't have to reload the watch face after asserting the latest version.
Related
Since I upgraded my Android Studio installation to Bumblebee, the emulator has become unusable. It either crashes during startup or gets itself stuck so that the UI is unresponsive and the debugger either cannot install or cannot launch an app. The way in which it fails varies from time to time for no reason that I can understand. although different virtual devices seem to behave differently. I tried deleting my old virtual devices and creating new ones, but that didn't help.
I can't debug my code on a real phone because of a different problem, see my recent answer to Source code does not match the bytecode for Android's View.java.
When it crashes I send a crash report to Google, but they don't seem to be fixing it. The problems started with the first official Bumblebee release 2021.1.1, which seemed to have a complete new version of the emulator, and I'm now on the latest stable version 2021.1.1 Patch 2.
My environment is a Dell Precision M4800 with 16GB of RAM and an 8-core Intel processor, using an external 4K monitor and an external full-size keyboard, running Linux openSUSE Leap 15.3 with all recommended patches installed.
Does anyone have any suggestion short of throwing away my entire Android Studio installation and reverting back to Arctic Fox? Has anyone else seen similar problems?
Tintin's answer didn't work for me: Device Frame wasn't enabled anyway because I had noticed that it had caused problems before.
However the following sequence rather surprisingly, at least to me, did fix the problem.
First make sure that the toolbar is visible at the top of the emulator window: if it isn't, click on the gear settings icon at the top right of the emulator window and enable Show Toolbar.
Start up an emulated virtual device, and before it crashes click on the three dots at the right hand end of the toolbar: this will bring up the extended controls window.
Choose Settings from the list at the left of the extended controls list.
Set the OpenGL ES renderer to Desktop native OpenGL, and the OpenGL ES API to Compatibility (OpenGL ES 1.1/2.0).
Close the extended controls window and then close the Android Emulator window.
Check if there are any zombie emulator or qemu processes still running. If there are, kill them: you'll need kill -9 on Linux.
Try to cold boot an emulated virtual device: it will probably crash before it even gets started up properly.
Close the Android Emulator window and repeat step 6
Try to cold boot an emulated virtual device again, but click on the three dots quickly before it crashes.
When the extended controls list comes up, choose Settings from the list at the left.
Set the OpenGL ES renderer back to SwiftShader, and the OpenGL ES API back to Renderer maximum (up to OpenGL ES 3.1).
Repeat steps 5 and 6.
Now try to boot up an emulated virtual device again. It should work: at least it does for me.
If it doesn't work on your configuration, try all possible combinations of the OpenGL ES settings: you may find one that works.
Logically, changing the OpenGL ES settings and then changing them back again shouldn't do anything, but it does. My guess is that perhaps some needed bit of initialisation for the OpenGL isn't being done by the installer, but it gets done when you change the configuration.
I also faced this problem in both updates in 2021.1.1 it was not working at all. Updated to patch 2 again faced problems turned off Enabled Device Frame it is working OK now
I am trying to set up the Divio app on Win10 Pro.
I can launch the application, log in, select the workspace folder for my project, so the required dependencies should be fine.
However when I click on "Set up my project", then a new window is opened with a text "Preparing logs...", and an animated "hour-glass" appears next to the "Open Shell" button in the lower-left corner, but that's it. Everything hangs up at this point, and I can't figure out what's wrong. Restarted the computer and the app several times, but with same results.
Any ideas how to work out what is going wrong?
The Divio app is an Electron application, and uses Chromium for the interface.
You can invoke its Inspector as you would in Chrome itself, using command-option-i on Macintosh and control-shift-i on Linux and Windows.
The Inspector's Console tab will show any errors, and this will help understand what is happening internally. Typically, they will be errors related to the operating system in some way.
On Windows 8.1, if you right-click on the taskbar and point to Toolbars you can turn on Touch Keyboard, which makes a small image of a keyboard appear at the far right of the task bar just to the left of the notification area.
I want to develop an application that can make a presence here with a dynamically updating display of a time string (a count down application).
Can anyone advise if this is possible using C# .NET?
From various research I've discovered it is extremely difficult to determine exactly what Microsoft refer to this utility as. I have seen 'deskbar', 'deskband' and obviously it's under 'toolbars' in the task bar context menu. It also seems every major OS release changes the terminology and functionality completely. So bonus points if anyone can clear up what it's called on Windows 8.1 in addition to what term to research or MSDN article to read about developing an application that sits there.
On my new and more powerfull Windows 10 PC I found AVD surprisingly slower. After some time I came to the conclusion that it is caused by highDPI screen (when connected to external monitor, its much faster). Why is that?
I created this question only to be answered straight away for other people to benefit. This is caused by DPI optimizations done by Win10 and has surprising effects on the outcoming speed of emulator.
To fix, go to Android SDK dir, for me it is
C:\Users\XXXX\AppData\Local\Android\sdk\tools
Now right-click emulator.exe, open Properties, go to Compatibility and select Disable DPI Optimizations under Settings
Do the same for emulator-x86.exe.
Restart your AVD. Not only will the emulator be brighter and clearer, itll also be more responsive and much faster to work with when debugging.
I realise many people consider this obvious, and they changed these settings straight away, but it didnt occure to me as Android Studio is High DPI monitor friendly and doesnt require to be launched in optimised way by Windows. So when emulators are launched from within a highdpi supporting app, I would expect them to be also highdpi compatible.
The more I look around, the more it looks like this feature just isn't supported.
When I try to run the graphics diagnostics tools, it just launches the app and debugs normally. I see nothing new that is related to graphics anywhere on the screen (every button on the graphics toolbar is grayed out).
I'm surprised I wasn't able to get an answer from my search engine, but I would love guidance so I could try some other form of debugging instead.
Thanks for reading