Announcement

Collapse
No announcement yet.

OSDash Interface Discussion

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • OSDash Interface Discussion

    As I have been pouring over the entire OSDash thread, and being an "Interface" guy, I thought an iPhone interface would be a good idea. It would allow you to access many of the feature of the OSDash project. Such as Vehicle Information, Playlist management, I would even go as far as being able to start your vehicle, and set the temperature, turn on or off the head lights, etc. Given, of course, that you have the proper hardware/software to do such things.

    EDIT::::

    I renamed this thread to "Interface Discussion" as it has been clear that we need to flesh out what types of interfaces there will be available. Separate threads will need to be created for the development of the various interface softwares, such as: iPhone, Android, Blackberry, WAP, Web. These interfaces should be uniform enough that you would be able to switch between one and the other, without any learning curve.
    - Project: Unified Car Control
    - Original OpenMobile Interface Designer

  • #2
    I think a phone interface is an excellent idea. Once they solidify the functionality and the API's I was planning on starting an Android interface. Would you be interested in working together to ensure the Android and iphone interfaces provide a similar experience? I think it would be beneficial for both to be similar enough that a user can go from one to the other without much difficulty,
    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
    RevFE
    My Shop

    Comment


    • #3
      I would always be more than willing to collaborate with others on great projects such as this. My only thing is I am not a programmer. I am a graphic designer and have done extensive study on interface design.

      So as far as working with you to create a uniformly designed interface between Android and the iPhone. I would also like to create a simple WAP interface for other not so capable phones.
      - Project: Unified Car Control
      - Original OpenMobile Interface Designer

      Comment


      • #4
        Can I suggest that we make this a compound project? By that, I mean the use of the iPhone or the Android to control another device that can make the functions you describe happen.

        That device would function as a helper to the iPhone or the Android. I am thinking in particular of a Sheeva plug which runs embedded Linux.

        You may or may not know that I have been experimenting with this type of setup and have figured the basics of communicating from the iPhone to the Sheeva via web browser. The Sheeva runs a web server and can execute any commands one wishes using php.

        The Linux client for OSDash should run on the Sheeva, giving your mobile device two functions: 1. Provide the connection to the internet for the client on the Sheeva; 2. control the functions on the Sheeva from the iPhone.

        There are advantages and disadvantages to this browser front-end approach. The primary disadvantage is that you are limited to the browser for the interface. The web page that will serve as the interface could be served from the Sheeva plug itself and updates to the interface would be downloaded from the net -perhaps as a service of OSDash.

        The advantage is that you are not limited to controlling your car from your phone. Any web browser becomes your interface. In effect, you are distributing computing across platforms and tying them together using the web browser as the interface. You carry your car computer with you.
        Originally posted by ghettocruzer
        I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
        Want to:
        -Find out about the new iBug iPad install?
        -Find out about carPC's in just 5 minutes? View the Car PC 101 video

        Comment


        • #5
          I see the primary disadvantage of that is the sheeva itself. Personally I don't want anything above the microcontroller level on in my car 24/7 for battery concerns, so you're limiting this to people who can and want that infrastructure. Browser interfaces are fine for phones that don't have the ability to run custom applications.... but why ignore phones with a rich programming environment? It will allow for a much smoother and faster interface imo.
          "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
          RevFE
          My Shop

          Comment


          • #6
            It was my understanding that their would be a web interface for OSDash. What I propose is three additional interfaces be created, possibly four:
            1) iPhone/iPod Touch
            2) Android
            3) WAP Cell Phones
            4) Blackberry (if someone comes forward to develop)

            This way there will be separate, yet uniform interfaces that allow you to interface with the OSDash web services. I think to interface with the Sheeva plug could be built into any and all of the above mentioned interfaces, but I do not think it is directly related to this idea.

            If we are going to do this, I propose we create a separate thread for each of this clients.
            - Project: Unified Car Control
            - Original OpenMobile Interface Designer

            Comment


            • #7
              The OSDash web interface is a control panel and settings interface. It is not a web front end for car computing. Instead, it is a way for you to easily configure which services you are using and make personalized settings according to your user I.D.

              The second part of OSDash is the server, which handles those settings and the OSDash compliant services.

              Both of these pieces are independent of the operating system that you use.

              The third piece, which is customized to each operating system is the client. The client interfaces with the server but most likely will not have a gui. It is a background process that can be called on by a front end, or a single application. The point is to allow web services to be available across platforms allowing them to be written once and used by everyone.

              What you are proposing is a front end for each of the phones that can interface with the client and use OSDash services. There is nothing wrong with this but you will first need an OSDash client for each of the phone's operating systems followed by a front end app for each of the phones that calls the client for its services.

              Malcom, your point is well taken about a rich programming environment. Following that out to its logical end, what is the point of making the interfaces appear to be the same on different hardware platforms with different capabilities such as multitouch?

              Maybe I misinterpreted what you want to do, but if you don't use something like a Sheeva, what exactly will you be running 24/7 to make the car start or to set the temperature and turn on the headlights?
              Originally posted by ghettocruzer
              I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
              Want to:
              -Find out about the new iBug iPad install?
              -Find out about carPC's in just 5 minutes? View the Car PC 101 video

              Comment


              • #8
                Originally posted by Bugbyte View Post
                What you are proposing is a front end for each of the phones that can interface with the client and use OSDash services. There is nothing wrong with this but you will first need an OSDash client for each of the phone's operating systems followed by a front end app for each of the phones that calls the client for its services.
                While I respect the architecture of OSDash and understand the purpose of a separate client application on a carpc, on a phone I see no reason to separate the GUI application from the client process especailly on the Android OS. The only reason to run a service on Android is if you need to do active processing when the user isn't looking at the GUI, which should not be happening (Unless I missed a reason why it should?).

                Originally posted by Bugbyte View Post
                Malcom, your point is well taken about a rich programming environment. Following that out to its logical end, what is the point of making the interfaces appear to be the same on different hardware platforms with different capabilities such as multitouch?
                I mean the same look and menu configurations, not so much as the exact same interface. That will be impossible, due to the nature of Android vs iPhone application life cycles at the very least. My point was to make it so a user could go from one to the next, and still feel "at home" with the process. Use the same application flowchart to design each of the applications perhaps.

                Originally posted by Bugbyte View Post
                Maybe I misinterpreted what you want to do, but if you don't use something like a Sheeva, what exactly will you be running 24/7 to make the car start or to set the temperature and turn on the headlights?
                I'm hoping you misinterpreted me, and not the other way around . I was thinking more to use the services to set up a trip before you leave. You set your GPS destination, POI's you want along the way, maybe set up a playlist to be played when you hop in the car to go. Then when you get in the car, start it up and start pulling away the PC turns on, grabs all the information from the internet (including relavent traffic and weather data) and starts you going. If I'm wrong about what OSDash can do, by all means correct me, this whole concept is new to me.

                Of course, in your scenario where you have the sheeva, why not have the temperature set, headlights etc, all accessible via OSDash directly, or if the phone is going to talk directly to the sheeva then just bypass OSDash entirely which is another application in and of itself.
                "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
                RevFE
                My Shop

                Comment


                • #9
                  (Graphic Designer trying to understand programming….)

                  Okay, now I understand a little better, lets see if I get this right.

                  If I want this to work out, what would have to be done is have a “client” on the said device, such as the iPhone and Android powered phone. This “client” would communicate with the “server-side” software. And then I would need a “iPhone FE Software” to communicate with the “client” to get the data.

                  What if there was a web-based “client” software? I am not sure about other platforms, but I do know that the iPhone would never allow a “client” software on it. So if anything it would have to be a client/FE hybrid, which seems very limited to each platform, and not very productive.

                  It would make more sense to create a web-based “client” that different “control software” on different clients can all access and make use of.

                  Also, i think that if you were to develop this software to work just with the Sheeva plug, you would be limiting its future potential for when someone comes up with an alternative solution to the Sheeva plug. (not that I am currently aware of, but you never know) It seems smarter to program with future technology in mind, then be limited by current hardware. You would hate to have to rewrite the software later down the road.
                  - Project: Unified Car Control
                  - Original OpenMobile Interface Designer

                  Comment


                  • #10
                    Originally posted by malcom2073 View Post
                    While I respect the architecture of OSDash and understand the purpose of a separate client application on a carpc, on a phone I see no reason to separate the GUI application from the client process especailly on the Android OS. The only reason to run a service on Android is if you need to do active processing when the user isn't looking at the GUI, which should not be happening (Unless I missed a reason why it should?).
                    The "Client" is implementation specific. On the Android, and many other platforms, it makes sense to have the client be the GUI. That GUI could be a web page or an Android app. On windows, the client will likely be running in the FE process in many cases.


                    The OSDash web interface is a control panel and settings interface. It is not a web front end for car computing. Instead, it is a way for you to easily configure which services you are using and make personalized settings according to your user I.D.
                    I hope the web interface will expand in time to be able to display information that your car produces.
                    Former author of LinuxICE, nghost, nobdy.
                    Current author of Automotive Message Broker (AMB).
                    Works on Tizen IVI. Does not represent anyone or anything but himself.

                    Comment


                    • #11
                      Originally posted by kev000 View Post
                      I hope the web interface will expand in time to be able to display information that your car produces.
                      Agreed. Just didn't want to go there in this thread.
                      Originally posted by ghettocruzer
                      I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
                      Want to:
                      -Find out about the new iBug iPad install?
                      -Find out about carPC's in just 5 minutes? View the Car PC 101 video

                      Comment


                      • #12
                        Originally posted by UnusuallyGenius View Post
                        (Graphic Designer trying to understand programming….)
                        What if there was a web-based “client” software? I am not sure about other platforms, but I do know that the iPhone would never allow a “client” software on it. So if anything it would have to be a client/FE hybrid, which seems very limited to each platform, and not very productive.

                        It would make more sense to create a web-based “client” that different “control software” on different clients can all access and make use of.

                        Also, i think that if you were to develop this software to work just with the Sheeva plug, you would be limiting its future potential for when someone comes up with an alternative solution to the Sheeva plug. (not that I am currently aware of, but you never know) It seems smarter to program with future technology in mind, then be limited by current hardware. You would hate to have to rewrite the software later down the road.
                        You've got the basics figured out. I intend to use the Sheeva to run the client software and serve up web control pages on the iPhone across WiFi as you described.

                        Sorry, I didn't mean to sidetrack this thread, so I'll finish up in this post and let you guys get back on track.
                        Originally posted by ghettocruzer
                        I was gung ho on building a PC [until] just recently. However, between my new phone having internet and GPS and all...and this kit...Im starting to have trouble justfiying it haha.
                        Want to:
                        -Find out about the new iBug iPad install?
                        -Find out about carPC's in just 5 minutes? View the Car PC 101 video

                        Comment


                        • #13
                          I renamed this thread to "Interface Discussion" as it has been clear that we need to flesh out what types of interfaces there will be available. Separate threads will need to be created for the development of the various interface softwares, such as: iPhone, Android, Blackberry, WAP, Web. These interfaces should be uniform enough that you would be able to switch between one and the other, without any learning curve.
                          - Project: Unified Car Control
                          - Original OpenMobile Interface Designer

                          Comment

                          Working...
                          X