Im a c# desktop developer and would like to start messing with mobile application development but i find that .net compact is a bit limited and slow.
What other freeware/open source tools are there ?
I recently found XFlib - it's intended mainly for games and it's still on an early stage of development, but looks really interesting and might probably be used for other kinds of software as well. For compiling it depends on ceGCC - an opensource compiler for ARM CPUs, and for development you can use pretty much any text editor/IDE:
http://www.xflib.net/
you could try this
Meme IDE is now available for download.
Build with a drag and drop editor. Develop complex functions using the unique MemeScript. A language created to make elements simple and cohesive on any platform.
It is currently in beta release and at the moment you can develop for Android and WM. IOS will be included in the full release and Blackberry further down the line.
OH and its FREE
find out more or download and play with it at www.memeapps.com
this is a community based beta release so we want to hear what you have to say about it
Hey everyone, I'm looking for a developer who will be willing to help and teach me how to make a kernel! I would like to be able to add anything I want; meaning I'm looking for someone to teacher how to edit and add things to make it my own, not just teach me how to compile. I've never made anything deal with a source code, meaning I've never made an AOSP ROM nor kernel; I have made some touchwiz based ROMs, but that's a bit different. I would like to start by making something for the nexus 7 (WiFi only) then moving my way to the GsIII (d2spr). I'm currently using opensuse 12.3 KDE 64-bit, on its own HDD. Please, if anyone could help me and teach me, it would be greatly greatly appreciated!!!
What hourly rate are you willing to pay? LOL
What I would recommend you do is to start simply by:
a) installing the current NDK
b) downloading a complete stock kernel build tree as a tarball (.tgz)
c) setting up a build environment and successfully build the kernel
d) unpack an existing boot image, stuff your kernel in there, & re-pack it
e) boot it on your device. Does it run? Congrats! You are a kernel-builder!
The reason that I suggest this outline plan above is that it initially avoids learning git & associated tools until after seeing something you've built running on the device; that's a confidence-booster. That's the good news.
The bad news is that becoming a *good* kernel dev from scratch means that you simultaneously are learning kernel coding conventions, build tree structuring, and kernel APIs *plus* achieving an excellent understanding of how git & gerrit work.
In addition to some amount of original source code mods authored by a kernel dev, they spend a fair amount of time integrating patch sets (commits) coming from unrelated kernel projects (e.g. Linux kernel mainline or kernel mods from unrelated devices). Learning simple operations (commits) in git is easy enough, but understanding branch creation & multi-way merge strategies in the face of cherry-picks coming from arbitrary places is a bit of a mind bender the first time through it.
And there is the issue of compliance with the GPL. As soon as you decide to make public your work, you have an obligation to publish your sources.
There is at least one way to do this simply: don't worry about git/gerrit/github at all - use whatever source code control system you want, including none at all. When you are ready to publish, you publish a patch kit that transforms a specific commit on some other developer's (or google!) tree to your tree. That should satisfy the GPL.
Another thing to consider is to build these skills in an incremental fashion: if you have in mind a very specific kernel modification of original authorship as a first project, why not consider submitting your kernel patches as pull requests to an existing developer's kernel tree? If your patch/mod rocks, other devs will incorporate it - and probably be much more willing to answer twisty questions from you. You scratch their back, they scratch yours.
The point of the above two strategies is that they allow you to build skills incrementally rather than needing to know everything before you can begin doing anything. Don't try to learn it all simultaneously.
cheers
bftb0 said:
What hourly rate are you willing to pay? LOL
What I would recommend you do is to start simply by:
a) installing the current NDK
b) downloading a complete stock kernel build tree as a tarball (.tgz)
c) setting up a build environment and successfully build the kernel
d) unpack an existing boot image, stuff your kernel in there, & re-pack it
e) boot it on your device. Does it run? Congrats! You are a kernel-builder!
The reason that I suggest this outline plan above is that it initially avoids learning git & associated tools until after seeing something you've built running on the device; that's a confidence-booster. That's the good news.
The bad news is that becoming a *good* kernel dev from scratch means that you simultaneously are learning kernel coding conventions, build tree structuring, and kernel APIs *plus* achieving an excellent understanding of how git & gerrit work.
In addition to some amount of original source code mods authored by a kernel dev, they spend a fair amount of time integrating patch sets (commits) coming from unrelated kernel projects (e.g. Linux kernel mainline or kernel mods from unrelated devices). Learning simple operations (commits) in git is easy enough, but understanding branch creation & multi-way merge strategies in the face of cherry-picks coming from arbitrary places is a bit of a mind bender the first time through it.
And there is the issue of compliance with the GPL. As soon as you decide to make public your work, you have an obligation to publish your sources.
There is at least one way to do this simply: don't worry about git/gerrit/github at all - use whatever source code control system you want, including none at all. When you are ready to publish, you publish a patch kit that transforms a specific commit on some other developer's (or google!) tree to your tree. That should satisfy the GPL.
Another thing to consider is to build these skills in an incremental fashion: if you have in mind a very specific kernel modification of original authorship as a first project, why not consider submitting your kernel patches as pull requests to an existing developer's kernel tree? If your patch/mod rocks, other devs will incorporate it - and probably be much more willing to answer twisty questions from you. You scratch their back, they scratch yours.
The point of the above two strategies is that they allow you to build skills incrementally rather than needing to know everything before you can begin doing anything. Don't try to learn it all simultaneously.
cheers
Click to expand...
Click to collapse
Wow, okay, thank you! I'll start with that. Honestly I like having someone just point me in the directions then me teach myself the rest! That is probably the best thing to do all around. I just have somethings:
1.) If I get lost somewhere and am not able to find answer for something anywhere; do you mind if I PM you?
2.) Almost everywhere I read---including from source.android.com---it say, use Ubuntu; why? Do I have to? Ubuntu doesn't support my graphics card---and isn't easy to set up, even when using things from other OSes or just other stuff someone made---which is kinda needed because of my monitors.
jamcar said:
2.) Almost everywhere I read---including from source.android.com---it say, use Ubuntu; why? Do I have to? Ubuntu doesn't support my graphics card---and isn't easy to set up, even when using things from other OSes or just other stuff someone made---which is kinda needed because of my monitors.
Click to expand...
Click to collapse
I've used Unix/Linux for quite a long time, and if there is one thing that seems to never change is package dependency differences from distro to distro. Getting them resolved is mandatory (when you are stopped out by them), but typically quite a distraction from whatever it is you are trying to accomplish.
By using Ubuntu you will be following the footsteps of many others in front of you (including Google developers), and that means that when you encounter a problem, it will be very likely that exact problem has already been encountered and resolved, and you can find the solutions on the internet. That may not be the case for some other arbitrary distro. So, why make your life more difficult?
As far as kernel development goes, you can do anything you want inside a VM, assuming your machine has enough ram (say 4+ GB) and disk space (say 100G free). So get VirtualBox and create an Ubuntu VM.
There are small downsides to using a VM, but for code-building they are just fine - their performance in doing kernel builds is probably 95% of native metal.
jamcar said:
1.) If I get lost somewhere and am not able to find answer for something anywhere; do you mind if I PM you?
Click to expand...
Click to collapse
I would never commit to something open-ended like that - esp. since you said you have never coded anything before. You are free to PM me though, so long as you understand that I am free to choose not to reply. Given those ground rules, it might be better for you to just post your questions in public (say stackoverflow.com) so more eyeballs will see what you are asking.
cheers and good luck - you've chosen a pretty steep mountain to climb.
Pronounced "say candy", the goal of SecAndy is to come up with as secure and private of an OS as possible. So as not to reinvent the wheel, we'll base this initiative on our open source code of choice (Android or maybe other developers' choice).
I am not a developer myself but I can without a doubt, because of former professional experiences, organize a project and gather the right people together as a community in order to make sure that project sees the light of day after it has acquired a life of its own if needed, which I think we will agree is something that this kind of project requires because of the scrutiny it will quickly attract.
I am officially calling upon this post all interested developers that could help us fork Android or other open source OS.
Let's get a kickstarter funded and let the party begin. I will update you later today on the advancement of such.
Due to the fact that I'm a new member here, I can't post outside links, you'll have to copy/paste them, sorry for the inconvenience.
What is B2G OS?
The Boot to Gecko (B2G) project was started [1] in 2011 to build a complete, standalone operating system for the open web. B2G is a community maintained open source project based on the Linux kernel and Gecko rendering engine and has been used as the basis of commercial Firefox OS smartphone and smart TV products.
In December 2015 the Mozilla Corporation announced [2] it was shifting its focus away from smartphones to other types of connected devices [3]. Since then a transition project [4] has been underway to modernize B2G and create a leaner platform on which to build smart TVs and other potential connected devices products in the future. As part of this transition, Mozilla's community of volunteers is taking ownership over the smartphone-specific parts of B2G so that Mozilla employees can focus their efforts elsewhere.
The transition project aims to replace Mozilla's legacy app runtime with new standards-based web apps and move the core B2G system closer to the architecture of the Firefox web browser. This will reduce complexity and maintenance costs and create a platform for the future based on emerging web standards.
Why Do We Need Your Help?
Maintaining an operating system is a big project and a large community of volunteers is needed if we are to keep B2G running on the smartphone form factor. There are many ways to contribute such as building and testing the OS, filing and fixing bugs, developing new features, porting to new devices, helping with documentation and localization and even just using and talking about the B2G project.
Help is already needed on the transition project to get core system features working, port smartphone apps to the new architecture and document everything which has changed. Once the transition is complete we hope to build an even bigger community of contributors to help making B2G move forward.
If you're interested in the challenge of helping to maintain a complete, standalone operating system for the open web, then we want to hear from you! B2G is made by the community for the community and we need your help.
How to Get Started
There are many ways to get in touch with the B2G community including the main forum [5], the dev-fxos mailing list [6], our #fxos IRC channel for real-time chat [6] and telegram group [7] for more general and informal discussions. We also hold weekly public meetings [8] on Vidyo where you can catch up with the latest news and meet other members of the team.
See B2G OS [9] on MDN for a list of ways you can get involved depending on your particular interests.
1. https://wiki.mozilla.org/Booting_to_the_Web
2. https://blog.mozilla.org/blog/2015/12/09/firefox-os-pivot-to-connected-devices/
3. https://wiki.mozilla.org/Connected_Devices
4. https://wiki.mozilla.org/B2G/Transition_Project
5. https://discourse.mozilla-community.org/c/firefox-os-participation
6. https://wiki.mozilla.org/IRC
7. https://telegram.me/B2GOS
8. https://wiki.mozilla.org/B2G/Meeting
9. https://developer.mozilla.org/en-US/docs/Mozilla/B2G_OS
Hello everyone,
My team is working for eeGeo, a company that provides a 3D mapping platform for developers.
A cloud based, SaaS platform has its origins in the gaming industry. We use gaming know-how married to mobile technology and big data to create geo-spatially accurate renditions of cities, countries and continents for multiple platforms.
eeGeo’s SDK makes it simple to create and maintain an engaging virtual representation of any property (outdoor as well as indoor).
Big news is that we have recently launched our JavaScript API which promises to greatly reduce the friction to developing on our maps; you can hack something up rapidly, rather than installing xcode, signing up for a developer account , provisioning your device etc. Plus you don’t need to download any app to experience our maps.
In addition to that, our API is compatible with the popular Leaflet.js library, used by many mapping platforms. If you’re already using Leaflet, it’s easy to change your 2D map for a more immersive, engaging experience. It’s all out there courtesy a few lines of HTML.
More details here: http://www.eegeo.com/2016/07/eegeo-maps-browser-javascript-api-now-beta/
It would be brilliant if you could become a part of the team that will test run our JavaScript API, eegeo.js and get back to us with your feedback. We are offering a free license of our eeGeo SDK worth $1200 for everyone who participates.
Do note that this is a beta release, so we’d love to hear your feedback. We’re already planning performance improvements, increased map coverage, and new features, but we want to hear from you. Feature requests, bugs, and other comments can be added to the github issues list.
During the beta period, eegeo.js is free to use. You only need an eeGeo API key. You can sign up here: https://goo.gl/forms/l2Wh2M9wkqw9kqXq1. Have a great day!