Sign up for our newsletter! 
Home News Products Downloads Forum Distributors Store Contact Us
PPE User Forum
January 16, 2018, 08:01:53 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: 1 2 [All]
  Print  
Author Topic: Suggestions for making skin management better  (Read 9268 times)
0 Members and 1 Guest are viewing this topic.
zra
Newbie
*
Offline Offline

Posts: 8


View Profile
« on: May 17, 2012, 06:35:39 pm »

Installing skins, switching skins, and finding skins on the site is overly complicated and difficult. And the skins that are available are not easily modified by the normal user.

Some things I think would make it easier in no particular order:

1. The ability to package a portrait and landscape skin so that turning the phone would display the one which is optimized for that orientation or at least, on the settings page, let the user choose which skin should be used for which orientation. Then you could pre-load 2 skins and then change them by rotating the device.

2. Doing whatever is involved in registering DashCommand so that it will show up in the list of "Open In" apps on the iPhone, this way one could go to the full site or even an FTP (for those doing skin development) site and tap and hold a file of the appropriate type and have it open in Dash command.

3. Break out the Skins section in DashCommad instead of having it buried inside settings.

4. Let the user select multiple skins that can be toggled through on the fly from the Dashboards section Maybe with a Down Swipe or other gesture or an additional one of those big ugly buttons that you get when tapping the screen now?

5. Have Palmer Employees vet the skins that actually work and put them in a different section from the experimental and partially finished ones. And until The user can change skin display parameters on the device (see #6 & #7) A page with the dozens of Stock Tuxedo Skins with only one parameter changed. Individual user pages with all their skins displayed (like Firefox theme pages) would be good too.

6. A separate section for Metric and US skins, unless you can come up with an easy way for the user to select a different calc on the device (see #7)

7. Make skins that the user can tweak on the device. The first default page of the Tuxedo skin is a good start, but let's say instead of Accel data I want instant MPG in that spot, I should be able to enter edit mode on my iPhone and change what is displayed in that column. Even if you designed a skin that was less visually interesting but tweakable on the iPhone, that would be great The Data Log page sort of works like this, but it's display is terrible. A skinnable Data Log page would be a good place to start.

8. Easy iTunes drag and drop installation, removal, rename of skins. I can see the DashXL folder but I can't open it or put anything in it from iTunes.

9. An animated gif of each skin page on the site with 10 frames showing the full sweep of the gauge's values from 0-100%

10. The user should be able to rotate  between pages at a defined interval. So I could, for example, in Dashboard mode Show performance for 20 secs then show Mileage page for 10 secs. then show Trip B for 10 seconds. Or even better let me choose different skin pages so I could say, go from the Boost skin to the Tuxedo Performance page every 5 seconds.

11. It would be nice to be able to reconfigure the icons on the main DashCommand page so I could have settings on the same page as Dashboards, until you implement a totally different skin switching scheme. Or maybe get rid of the icons and make it a list view so it all fits on one screen.

12. How about a modern WISYWIG skin editor that could be cross platform Mac/PC/Linux?

I realize that you guys are trying to maximize your profit by developing for as few platforms as possible, but at the price point for DashCommand, I expect to have an iPhone app that is written for and takes advantage of the iPhone and not something that kinda works ok and similarly on iPhone and Android.

Hope this helps.

If you want an iPhone/iPad Beta tester I'm willing to give clear notes and try technical fixes.
Logged
cannonballgsu
Newbie
*
Offline Offline

Posts: 6


View Profile
« Reply #1 on: May 18, 2012, 08:19:35 am »

Excellent recommendations!!!  I agree to all of them, especially the ability to change which parameters are displayed on each screen (i.e. change acceleration for instant mpg).


I do have a couple other minor suggestions:

When I'm trying to swipe through the guages, quite often, the menu pops up instead of the screens swiping.  Maybe you could just add a menu key to the bottom so this is avoidable.  Also, since the entire app is so visually appealing, make the menu buttons match the app.

I also want to mention that I love the app, and while I've only REALLY used it to diagnose some problems, I've had a blast playing around with the features.  Since the latest update, it has been running much much more smoothly on my iphone (4s) and ipad (2).  Keep up the good work!!!
Logged
Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #2 on: May 18, 2012, 11:15:27 am »

Thanks for your suggestions! We have been talking around the office recently about many of these things already. While we do want to update this, we're still working on it and (unfortunately) it does take a back seat to real bugs.

Currently, our thoughts are along these lines:

- Design a way to include portrait and landscape into a single skin set (we do have a few theories on this).
- Add a button to the pop-up menu to change or switch the current skin set.
- Try to improve the iTunes file sharing.
- Long tap (touch & hold) to open pop-up menu, to avoid missed taps.
- Allow DashXL.net log in to rate skin sets from the phone?

If you guys have any other comments we'd be glad to hear them.
« Last Edit: May 22, 2012, 12:01:55 pm by Weston@PPE » Logged
zra
Newbie
*
Offline Offline

Posts: 8


View Profile
« Reply #3 on: May 22, 2012, 12:23:56 am »

There's one thing I left out, and this is actually a big one for an iPhone app which is used in a car. DC really needs to show (or at least the ability to show) the menu bar inside the app. Time, signal level, battery/charge status. Also the touch to return to call or the ability for DC to run in the background when consulting a GPS app and then switching back. If I answer a call via blue tooth or switch to WAZE to check my next turn for example, I have to pull over to re-establish communication with DC safely.
Logged
John@PPE
Hero Member
*****
Offline Offline

Posts: 3029


View Profile
« Reply #4 on: May 22, 2012, 09:29:25 am »

A lot of people have asked for DashCommand not to disconnect when switching apps. Unfortunately, the iPhone itself restricts this. When we are switched to the background we are unable to send data to the OBD-II unit. When the OBD-II unit gets no data for a few seconds, it auto-disconnects. Hopefully some day Apple will fix this, but for now all that we can do is to offer to auto-reconnect.

This guy does a pretty good job of explaining: http://ipod.about.com/od/usingios4/qt/How-Iphone-Multitasking-Works.htm

We do have a setting to show the menu bar. It's fullscreen mode. Switch that off and you can see the menu within DashCommand.
Logged
cannonballgsu
Newbie
*
Offline Offline

Posts: 6


View Profile
« Reply #5 on: June 20, 2012, 10:20:12 am »

I know you guys are busy with other stuff, but have you made any progress with the suggestions?
Logged
John@PPE
Hero Member
*****
Offline Offline

Posts: 3029


View Profile
« Reply #6 on: June 20, 2012, 10:47:24 am »

These changes are important to us, but we have some other items to finish up before starting to work on them.
Logged
cannonballgsu
Newbie
*
Offline Offline

Posts: 6


View Profile
« Reply #7 on: June 20, 2012, 11:36:25 am »

Understandable, thanks for the update.
Logged
pherthyl
Newbie
*
Offline Offline

Posts: 12


View Profile
« Reply #8 on: June 24, 2012, 08:47:59 pm »

A lot of people have asked for DashCommand not to disconnect when switching apps. Unfortunately, the iPhone itself restricts this. When we are switched to the background we are unable to send data to the OBD-II unit. When the OBD-II unit gets no data for a few seconds, it auto-disconnects. Hopefully some day Apple will fix this, but for now all that we can do is to offer to auto-reconnect.

This guy does a pretty good job of explaining: http://ipod.about.com/od/usingios4/qt/How-Iphone-Multitasking-Works.htm

Do you think it would be possible to keep up the communication with the unit when you receive location updates from iOS? 

For example, a GPS navigation app will be able to continue providing voice navigation in the background.  So it must be executing its own code in the background given that it is using the location profile. 

One would think that you could maintain a connection to the ODB unit in the time that you are allocated for processing while in the background when receiving location updates.  No?
Logged
Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #9 on: June 25, 2012, 01:18:12 pm »

Its true that Apple allows background time for certain reasons, including VoIP (internet calls), and GPS data, but none of their categories really match DashCommand very closely and we're afraid that it would get us rejected from the App Store. However, they did (not to long ago) add an extra category that we do fit under -- but with conditions that we can't meet.

Apple has recently changed their policies about background execution time, and I did look over them again extensively just about 2 weeks ago. The fine print says that you can sign up for notifications from things like a GPS location update, or an external hardware update, and you can then handle the notification and you get suspended to the backgroun again. You are given just a few seconds of execution and if you haven't finished yet, your app gets terminated. This is problematic for DashCommand because we need to make a request to the hardware before it will send us any data back, but iOS ONLY provides a way for you to data from the hardware first and then you reply to the hardware.

It would be extremely difficult to make an OBD-II connection work backwards like that. OBD-II isn't designed that way, and the ELM hardware interfaces aren't designed that way.

Unfortunately we can't use the GPS updates either because they aren't consistent enough. Many vehicles will drop the connect on us if we don't make some kind of request every 2-3 seconds, and GPS updates can be more than 3 seconds apart.

A final nail in the coffin is that (until iOS 5.X) we had no way to put any type of icon on the status bar to indicate that DashCommand is actively running and consuming battery.
Logged
pherthyl
Newbie
*
Offline Offline

Posts: 12


View Profile
« Reply #10 on: June 26, 2012, 10:34:54 am »

Thanks.  That clears things up.  I was thinking of making my own very simplified monitor app and look into using GPS location updates as a chance to keep the connection alive, but it seems like it might not be possible after all.   

Dashcommand mostly works well, my own problem is that when it is running the foreground it uses almost all the CPU time on the phone, so running TomTom in the background is quite inconsistent.  Sometimes it will give me voice guidance, but with the phone being overloaded it will sometimes tell me too late, or the voice will be cut off.

I'm currently making a highly simplified skin to show just the info I need in its simplest form, hoping that that will improve performance. 
Any other suggestions to make DC use less CPU?  I hope that there isn't a busy loop on the UI redraw.. Smiley
Logged
Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #11 on: June 26, 2012, 11:38:19 am »

DashCommand v3.X has a few improvements for CPU use, mainly to save battery. We no longer redraw the dashboards as fast as we can, and only redraw them when something has changed. We also set it DashCommand to utilize multiple threads to help on devices like the iPhone 4S, iPad 2, and iPad 3 that have 2 CPU cores. You could also turn off persistent PIDs in the Settings to help reduce CPU load.

I uploaded a very fast skin set just a few days ago called Grand Prix. Before you spend all the time making yours, you might want to try out a few to see if it helps with background nav apps.

What device are you using?
Logged
pherthyl
Newbie
*
Offline Offline

Posts: 12


View Profile
« Reply #12 on: June 26, 2012, 07:48:57 pm »

Thanks.  I will try out the Grand Prix skin.  I have an iPhone 4.
Eventually I want just a one page skin to display only the fuel flow/consumption and the engine load.  Seems like the most useful parameters for driving more efficiently on an automatic.  

I am hoping not to have to disable the persistent PIDs because I do mostly want it to track the fuel (although with a fast simple skin it would be fine to have it loaded all the time).

Sorry for hijacking the thread BTW Smiley
Logged
pherthyl
Newbie
*
Offline Offline

Posts: 12


View Profile
« Reply #13 on: June 28, 2012, 02:09:22 am »

Did some testing.  The simple skin improved things a bit.  The voice on the GPS was no longer being cut off mid sentence, but it still was getting behind after a few minutes of driving.  To the point where after 10 minutes it was telling me to turn a good 30 seconds after I've already turned.

Then I turned off persistent PIDs and everything worked.  No more noticeable impact on the GPS in the background.

Seems odd though.  Based on the description and the manual, persistent PIDs are only there to keep monitoring when the dashboard isn't loaded.  So if I'm looking at the dashboard anyway, shouldn't there not be a difference?  I'm monitoring those PIDs by having the dashboard loaded, so I don't see why the background monitoring should use more CPU.  Or do I have that wrong?
Logged
Weston@PPE
Administrator
Hero Member
*****
Offline Offline

Posts: 2234


View Profile
« Reply #14 on: June 28, 2012, 11:25:19 am »

The persistent PIDs is a list of PIDs that are always monitored, no matter what screen you are looking at. If you're looking at the Engine 1 dashboard, the persistent PIDs will be monitoring ALL of the trip PIDs, and ALL of the fuel economy PIDs for you. It does take a significant amount of CPU time to do all of those calculations several times per second.

Even if you're looking at the fuel economy dashboard, you don't need to trip PIDs in the background -- its things like this that make the difference even while you're watching a dashboard.
Logged
John@PPE
Hero Member
*****
Offline Offline

Posts: 3029


View Profile
« Reply #15 on: June 28, 2012, 02:01:05 pm »

You can also change which PIDs are persistantly monitored. Check in the setting for the list.

But note that the CALC PIDs are calculated PIDs, which usually require many SAE PIDs to be monitored.
Logged
pherthyl
Newbie
*
Offline Offline

Posts: 12


View Profile
« Reply #16 on: June 28, 2012, 10:50:32 pm »

Gotcha. Thanks!
Logged
Pages: 1 2 [All]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.13 | SMF © 2006-2011, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 0.089 seconds with 20 queries.
Home | News | Products | Downloads | Forum | Distributors | Store | Contact Us
Copyright © 2013 Palmer Performance Engineering, Inc. All Rights Reserved.