Reply
Thread Tools
Posts: 1,096 | Thanked: 2,084 times | Joined on Jun 2011 @ Finland
#11
Originally Posted by Try Catch View Post
2. I don't like the current time selection lists very much. If you keep them, change the minute list to 5 minute intervals, most users won't need to set it to an exact minute and scrolling is reduced significantly.

3. If possible it would be great to have the N9 time dial (as in alarms) for time selection. I'd really like that :-).
I don't like the time selection list either. I'd surely use the N9 time dial if possible, but unfortunately it has not been made for applications using QML Components. At least not yet. There's only that somewhat cumbersome time selection list, and AFAIK there's no control to make it in 5 minute intervals. I could of course code my own, but it's something I don't want to use limited time into.

I hope we won't be stuck with that time selector forever.

4. Provide a Wifi in range event. I work at different times during the day and like to have silent when in Office Wifi and normal when I leave or go to lunch.
Good suggestion. Seen that from other people as well. I'll add it into my TODO list.

5. Its impractical to leave the app open all the time. Use the Harmattan "timed" (http://meego.gitorious.org/meego-middleware/timed/) to schedule events or write your own daemon (http://harmattan-dev.nokia.com/docs/...g_daemons.html).
Will do. A daemon is the only flexible enough solution since in future the application is not only time based.

6. Have a look at Nokia Situations (http://betalabs.nokia.com/apps/nokia-situations), plenty more ideas for you.
Good stuff. Seems to have many of the things I want to do.
 
Posts: 1,096 | Thanked: 2,084 times | Joined on Jun 2011 @ Finland
#12
Originally Posted by noetus View Post
The reason being, I suppose, that the application is designed to change the profile setting automatically because it's hard to remember to do that manually. If you then have to remember to start the app manually to actually do that, then it defeats the purpose a bit doesn't it ;-)
Good point.

I think based on the user feedback that the background switching version must be the next release.
 
Posts: 311 | Thanked: 110 times | Joined on Nov 2007 @ Boston, MA
#13
Great app but what about by geographic location either by cell tower id (fast and no gps overhead) or by GPS location i.e. I had a similar app installed on my last phone (android gap phone between N900 and N9) and I would have it switch to silent when I was in class and when I was in work. The rules were not time based but location based.

Also what about the potential for a rule which would take effect depending on the orientation of the phone - i.e. flip it over so that the screen is pointing down etc.

Also time is good but it would be nice if you could set the start and the end time for a rule instead of setting two rules. Also a default mode rule which would take effect if none of the other rules were in effect.
 

The Following User Says Thank You to jer006 For This Useful Post:
Posts: 272 | Thanked: 299 times | Joined on Jan 2010
#14
Thanks for your great app!

Just stating like most people that it should definitely be a daemon in the background. Also, a WiFi based rule is really handy. Different profile for home and work.

As an ex N900 user, I sorely miss firing a script of my own when an event occurs. I have a few things around the house that I can control using HTTP requests and it would be awesome to be able to send one when something happens (alarm goes off, profile changes at some set time interval, home wifi is found, etc...). I realise this is probably way beyond the scope of your app but I like to ramble

Thanks again!
 
Posts: 1,096 | Thanked: 2,084 times | Joined on Jun 2011 @ Finland
#15
Originally Posted by jer006 View Post
Great app but what about by geographic location either by cell tower id (fast and no gps overhead) or by GPS location i.e. I had a similar app installed on my last phone (android gap phone between N900 and N9) and I would have it switch to silent when I was in class and when I was in work. The rules were not time based but location based.
This kind of rules are definitely in the "roadmap".

Also what about the potential for a rule which would take effect depending on the orientation of the phone - i.e. flip it over so that the screen is pointing down etc.
Not sure about that... Thinking about it, it seems too often recurring incidence (also by accident) that making rules based on that would not make sense. Do you have some concrete example in mind?

Also time is good but it would be nice if you could set the start and the end time for a rule instead of setting two rules. Also a default mode rule which would take effect if none of the other rules were in effect.
I started out with having an end range for time. But during implementation I came to the conclusion that when having only time/date based rules like the current version has, it only adds to complexity and would make the behavior of the program less easy to understand. Example: start time 8am, end time 10am, set profile silent. What if the user manually switches the profile between 8am and 10am? Does ProfileMatic restore at 10am the profile that was before 8am or keep the one that was manually set? Also then there is the issue of overlapping rules. All in all it just adds to complexity without real benefit. I also started out with a default rule but it has similar kinds of problems.

That said, end time will be needed for location based rules. It may turn out default rule will be needed then also. I'll see about then.

Thanks for the feedback.
 

The Following User Says Thank You to ajalkane For This Useful Post:
Posts: 1,096 | Thanked: 2,084 times | Joined on Jun 2011 @ Finland
#16
Originally Posted by slarti View Post
Thanks for your great app!
Thanks.

Just stating like most people that it should definitely be a daemon in the background.
I've started working on that. The next release will be about having a background daemon as it's the most requested feature.

Also, a WiFi based rule is really handy. Different profile for home and work.
Agreed. This goes with the other location based rules. I'm not sure in what order I will do these, GPS/AGPS/Cell based rules or WiFi first, but I intend to implement this also.

As an ex N900 user, I sorely miss firing a script of my own when an event occurs. I have a few things around the house that I can control using HTTP requests and it would be awesome to be able to send one when something happens (alarm goes off, profile changes at some set time interval, home wifi is found, etc...). I realise this is probably way beyond the scope of your app but I like to ramble
I'm not opposed to building some sort of support for running scripts as an action. It'd probably be a "pro" user kind of thing, like editing yourself the configuration file. So if and when ProfileMatic has "conditions" that do some action and you'd like to fire a script at the same time, let me know. I'll see about what's the best way to have support for it then.

Last edited by ajalkane; 11-11-2011 at 06:54 PM.
 

The Following 3 Users Say Thank You to ajalkane For This Useful Post:
Posts: 311 | Thanked: 110 times | Joined on Nov 2007 @ Boston, MA
#17
The product on android that I used before was locale which offers a wide range of customization options - http://www.twofortyfouram.com/product.html

I think one of those was phone orientation, I guess the idea I had in mind was to turn it over and automatically switch to silent profile or something along those lines.

The default rule worked really well in locale as it always set the phone back to a default state when no rule was in effect.

Regarding overlapping rules, would you enforce the logic that only a single rule/profile could be in effect at any given point in time? Does this really need to be enforced, ignoring this would potentially remove some of the complexity...

By the way, always great to see a developer actively engage the community.
 
Posts: 1,096 | Thanked: 2,084 times | Joined on Jun 2011 @ Finland
#18
Originally Posted by jer006 View Post
I think one of those was phone orientation, I guess the idea I had in mind was to turn it over and automatically switch to silent profile or something along those lines.
Sorry for long delay in responding due to various issues...

Thanks for the example. I can see how that can be useful. I'll add that to things to investigate.

The default rule worked really well in locale as it always set the phone back to a default state when no rule was in effect.

Regarding overlapping rules, would you enforce the logic that only a single rule/profile could be in effect at any given point in time? Does this really need to be enforced, ignoring this would potentially remove some of the complexity...
Not enforcing that rule might remove some of the complexity, but would probably raise some other issues. At least for the predictability of what rule is activated for user.

With ranged times a default rule is quite welcome, and at least solves the issue of having to keep state for what profile to restore. But ranged times are still more complex than only start time. With start times the algorithm becomes very simple: find the nearest start time and wait until it's reached. With ranges it becomes more complex: find nearest start or end time, wait until it's reached and then find out if time is inside any of the ranges. If inside several ranges, choose profile to use. If not inside any ranges, then use the default rule.

So I how I see the negatives:
- More complex implementation
- More possibilities for bugs
- Unclear operation with overlapping ranges

For me it doesn't seem worth it right now, just to avoid making a new rule. Making the rules is quite fast done, and as they're meant to automate common happenings they should not change often.

That's how I feel at the moment anyway, but all these suggestions and ideas are very welcome - they brew in my subconscious and when I advance with the application they might become very handy.

Thinking about this, the ranges and default rule are a possibility in the future. But ProfileMatic must have more comprehensive conditions (location based conditions etc.) before that makes sense.
 
Posts: 1,096 | Thanked: 2,084 times | Joined on Jun 2011 @ Finland
#19
Bad news: Setting flight mode programmatically seems not to be possible due to Harmattan's Security Policy. Same applies to setting Power Saving mode. I've dispatched a question to Nokia Developer forum about this, and I'm considering filing a bug report if the developer forum doesn't provide a solution:

http://www.developer.nokia.com/Commu...146#post872146

Good news: Running ProfileMatic on background is ready and was sent to Nokia Store last monday. So it's reasonable to expect it to arrive to store early next week, if it passes QA.
 

The Following User Says Thank You to ajalkane For This Useful Post:
Posts: 242 | Thanked: 345 times | Joined on Sep 2010
#20
So far I've understood that you can request policy restricted functionality from Nokia for your application, and they provide it in a certificate. I do not know how to request one though...
 

The Following User Says Thank You to Manatus For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT -4. The time now is 11:08 AM.