Cross platform team structure
-
We've been asked to investigate porting some of our apps to iOS and Android and WinPhone. Currently we are using C++ and target Windows/Lunix (html only version seperate to this). We split the app into 3 layers already, UI, MainLogic and MachineAccess (database, disk, network etc). I accept that UI and MachineAccess are platform specific, and I probably need developers and resources for each platform, but how should I handle the "mainlogic" ? This mainlogic layer is lots of lines (complex operations) and I dont really want to duplicate it and have to change it in multiple teams/codebases. Do I just have a mainlogic team that publishs the source to the platform teams? (publish and copy) This is kinda what we do for Win/unix but is there a better way? Having a single team on mainlogic is fine, I happy to break the workload along functional lines. I've also heard that WinPhone wont allow C++/C in the future - any bright ideas how to handle that? Yes we could re-code to a different language, but I suspect sooner or later this problem will occur again.
-
We've been asked to investigate porting some of our apps to iOS and Android and WinPhone. Currently we are using C++ and target Windows/Lunix (html only version seperate to this). We split the app into 3 layers already, UI, MainLogic and MachineAccess (database, disk, network etc). I accept that UI and MachineAccess are platform specific, and I probably need developers and resources for each platform, but how should I handle the "mainlogic" ? This mainlogic layer is lots of lines (complex operations) and I dont really want to duplicate it and have to change it in multiple teams/codebases. Do I just have a mainlogic team that publishs the source to the platform teams? (publish and copy) This is kinda what we do for Win/unix but is there a better way? Having a single team on mainlogic is fine, I happy to break the workload along functional lines. I've also heard that WinPhone wont allow C++/C in the future - any bright ideas how to handle that? Yes we could re-code to a different language, but I suspect sooner or later this problem will occur again.
Do you think that the mainlogic source will be different for the different platforms? Or only for certain portions? If the code is (for the most part) the same: Couldn't you use SCC and share the code over different projects? If the code is different, could you use an automatic code converter? We had worked out such a scenario for going from a dying language (VO) to .NET (Vulcan). During the transition period (a year) the code would be transported numerous times from VO to Vulcan until all of it would work. Parts would need a rewrite. The VO code would be adapted too if possible to make the transition possible. The VO code needed to produce valid apps all the time. An alternative: can you make an abstract in meta language for the 'complex operations'? You can use a code-generator to create the code you need in any language.
Regards ... OttO
-
We've been asked to investigate porting some of our apps to iOS and Android and WinPhone. Currently we are using C++ and target Windows/Lunix (html only version seperate to this). We split the app into 3 layers already, UI, MainLogic and MachineAccess (database, disk, network etc). I accept that UI and MachineAccess are platform specific, and I probably need developers and resources for each platform, but how should I handle the "mainlogic" ? This mainlogic layer is lots of lines (complex operations) and I dont really want to duplicate it and have to change it in multiple teams/codebases. Do I just have a mainlogic team that publishs the source to the platform teams? (publish and copy) This is kinda what we do for Win/unix but is there a better way? Having a single team on mainlogic is fine, I happy to break the workload along functional lines. I've also heard that WinPhone wont allow C++/C in the future - any bright ideas how to handle that? Yes we could re-code to a different language, but I suspect sooner or later this problem will occur again.
If users will typically have internet access on their devices, the main logic could be wrapped up as a web service. No need to throw any of that away, just build the interface. If the apps don't need access to things like cameras, email, contacts etc, create a HTML5 web page(s). That way the apps are no more than a pointer to the web pages. If this isn't an option, the only real commonality is potentially the webservice otherwise SQLite.
"You get that on the big jobs."
-
Do you think that the mainlogic source will be different for the different platforms? Or only for certain portions? If the code is (for the most part) the same: Couldn't you use SCC and share the code over different projects? If the code is different, could you use an automatic code converter? We had worked out such a scenario for going from a dying language (VO) to .NET (Vulcan). During the transition period (a year) the code would be transported numerous times from VO to Vulcan until all of it would work. Parts would need a rewrite. The VO code would be adapted too if possible to make the transition possible. The VO code needed to produce valid apps all the time. An alternative: can you make an abstract in meta language for the 'complex operations'? You can use a code-generator to create the code you need in any language.
Regards ... OttO
The mainlogic is identical on all platforms, it is essentially a pile of APIs and events. I had figured that SCC was the only way, but I thought there might be a better way now-a-days. Rewriting the mainlogic away from C++ to another meta language is possible, but the question is then what is a nice future proof generic meta language? To answer the next reply too - we do have a Web API layer already too (and HTML5 apps) - so I guess those platforms that cannot support C++ just have to use the Web API, unless there is a meta language that solves my problem. Thanx
-
The mainlogic is identical on all platforms, it is essentially a pile of APIs and events. I had figured that SCC was the only way, but I thought there might be a better way now-a-days. Rewriting the mainlogic away from C++ to another meta language is possible, but the question is then what is a nice future proof generic meta language? To answer the next reply too - we do have a Web API layer already too (and HTML5 apps) - so I guess those platforms that cannot support C++ just have to use the Web API, unless there is a meta language that solves my problem. Thanx
The beauty of a meta language is... you can create your own. It can also be a pitfall.
Regards ... OttO
-
We've been asked to investigate porting some of our apps to iOS and Android and WinPhone. Currently we are using C++ and target Windows/Lunix (html only version seperate to this). We split the app into 3 layers already, UI, MainLogic and MachineAccess (database, disk, network etc). I accept that UI and MachineAccess are platform specific, and I probably need developers and resources for each platform, but how should I handle the "mainlogic" ? This mainlogic layer is lots of lines (complex operations) and I dont really want to duplicate it and have to change it in multiple teams/codebases. Do I just have a mainlogic team that publishs the source to the platform teams? (publish and copy) This is kinda what we do for Win/unix but is there a better way? Having a single team on mainlogic is fine, I happy to break the workload along functional lines. I've also heard that WinPhone wont allow C++/C in the future - any bright ideas how to handle that? Yes we could re-code to a different language, but I suspect sooner or later this problem will occur again.
Richard Brett wrote:
but how should I handle the "mainlogic" ?
1. Analyze the existing code 2. Define a limited subset of C++ that allows you implement the existing code. This involves restricting features that currently exist in C++ (such as very limited template use.) 3. If necessary re-write the logic to match the subset of 2. 4. Create translators for the other target languages. Basically cross compilers that translate from 2 to other languages. 5. Add 4 into your build process for the main logic to insure that non-supported features do not creep in. 2/4 can be complex or simple depending on what the code does and what the target languages are.