Can anybody recommend gauge components for Compact Framework applications?
The only gauge toolkit that I've found so far is Perpetuum's Instrumentation Widgets for PDA. Perpetuum's gauges aren't visually appealing to me and also seem to be supported only up to .NET CF 2.0. Are there any alternatives?
At least one alternative is in smart device framework. http://www.opennetcf.com/library/sdf/
RoundGauge in OpenNETCF.Windows.Forms It isn't very fancy though so it may not be what you're looking for.
Related
I want to develop a framework like express. I am very keen to know the insides of Express-JS. Can some one suggest me how to develop a framework in Javascript and nodejs ? I cant find sources to learn how to develop framework in node ? please help me
Yes, you will not find sources because it is something hard to do,
Writing a framework is a big project that requires a broad understanding of what the framework will do, how it plans to accomplish it and most importantly embody the ideals that you have about developing front end architecture
If you're new, the breadth of your knowledge will be limited by your experiences.
How about focusing on making nifty tools or JavaScript-based programs
My scenario: trying to port a small part of an application created by our company from native code (ObjC for iOS / Java for Android) to C-Sharp. The project will interact with our webservices. Goal of this project is figuring out how feasible it is to port our whole app to Mono.
To create URLs, I'd like to use String.Format(). I thought it'd be a wise idea to put this 'service layer' inside a Portable Class Library (PCL) since I don't expect this code to change across platforms. Sadly, it seems the String library is not available for PCLs.
So my question is the following:
I think the main advantage of PCLs over "normal" libraries is that they shouldn't need a recompile for different platforms. Is this assumption correct?
This experience makes me think that for the moment PCLs are rather limited. Should I try to stick with PCLs and work around these kinds of issues, or might it be better to stick with a "normal" library for now? --- I'll assume the "normal" library has more functionality exposed.
You can use PCLs currently across many platforms, but it does require some small hacks to your setup.
These hacks are listed in http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
Once you've got those working then the functionality available is quite broad - and it definitely includes things like String.Format
For the situations where the PCL profile is not broad enough, then you can use several techniques for extending them - see http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx . The technique I generally use is to use MvvmCross Plugins - which are basically PCL interfaces with platform specific implementations. But these plugins are generally at the level of 'make bluetooth work' rather than at the level of String.Format
I do lots of PCL work across WinRT, WP, WPF, MonoTouch and Mono for Android - see http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html for lots of links to PCL work.
It's true that Xamarin have recommended not using PCLs for a couple of years, but that situation has now changed and the official support for PCLs is under way - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html
From a development perspective - especially from the point of view of using refactoring and testing tools - I don't hesitate to recommend you use PCLs now... especially for operations at the String.Format level. However, each project is unique... so it's not always the right answer.
One important note: right now it's better to not reuse the PCL binary files across to the MonoTouch platform - for now, build your portable libraries against the specific MonoTouch library platform. See http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html?m=1
Perhaps you want to look at the efforts other who have got PCLs working to a considerable degree with monotouch and monodroid.
For example see http://www.slideshare.net/cirrious/mvvm-cross-going-portable . You'll also find instructions on how to setup PCL support for MVVMCross here http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html .
Xamarin has recently committed to providing far greater PCL support rather than some of the workarounds that people have been having to make, but it is worth the effort.
I'm trying to build a dual platform application for a company of my own I'm trying to start at night.
I have the .NET version done, but have not finished the UI part. I'm thinking of buying some 3rd party controls.
If I buy these controls, however, they clearly will only work in my Windows version. I'm wondering if I should try to do the UI in GTK# and use Mono with CocoaSharp or just build the thing in MS technology and teach myself the Mac side?
I'm just really unfamiliar with the Mac world and am wondering how much of a learning curve there might be.
I've thought perhaps of rewriting my core logic in Ruby or Python. This why I could use the .NET version with .NET controls and presumably hook the same code up on the Mac.
It's an educational app targeted at consumers. As such, it shouldn't require a lot of technical sophistication to install.
If the non-visual part of the .NET application is quite big compared to the UI, then you can go full .NET and adopt the following two-steps strategy:
Non-Visual Part
Develop the non-visual .NET part to be the most platform independent.
Platform dependent code for non-visual code should be isolated in small classes that provide the same interface so they could be plugged according to the platform.
User Interface
Use System.Windows.Forms (or your favorite toolkit) for Windows
Use a Cocoa bridge (see this page for the choices) for Mac OS X.
You still can benefit from learning Objective-C: as the Cocoa bridges are usually heavily based on the Apple's API, you will find a lot of help in the Apple's sample code (which are in Objective-C).
On Windows, the application will run with the Microsoft .NET runtime and on Mac OS X, the application will run with the Mono runtime.
The DeepMeta application uses this strategy. As you can see the user experience is quite good on both platforms.
Avoid using cross platform UI tools; the result will never be as good as a native implementation, which is especially bad on the OS X where most customers expect a certain level of polish in their applications. Implementing the core logic in a platform independent language like C++ and maintaining a different code base for the interface on each platform can be a good solution, especially if you have a very complex model.
Anyway, you shouldn't have too much difficulty learning Cocoa if you're a good .NET programmer; I did the reverse several years ago and didn't have much trouble. Objective-C is more C oriented than C#, but if you know the basics about pointers and such you're going to be okay. Cocoa and .NET definitely have their differences in certain areas, but they're both high level frameworks which you shouldn't have too much trouble understanding. Get a good book (Hillegass is the go-to author) and go through it so you understand how the two APIs use different design patterns in certain areas, and don't try to fight the framework if it's different than what you're used to.
In my experience this will make you a better programmer in the long run by expanding your knowledge, even if you don't write any more Cocoa applications.
Looks like I found a good commercial variant, but I'm looking exactly for Free one. Does someone know some?
How about the OpenNETCF ORM? It's free, lightweight, and was built specifically for the Compact Framework, then ported to other platforms (as opposed to someone shoehorning a desktop ORM into the CF).
I am currently looking for a free .net ORM for use on Windows CE. So far I have found these commerical options:
DevXpress XPO
LLBLGenPro
EntitySpaces
NHibernate sadly is not an option because it uses features that are not available in the Compact Framework (e.g. reflection related functionality).
If using a SQL database as your underlying data store is not absolutely necessary then Karvonite is worth consideration. It is a free (Ms-PL) object persistence framework compatable with the .net Compact Framework. Do you need to use SQL Server Compact or are you really just wanting an easy way to persist your domain?
I will update you if I find more options.
I built DapperLite to work on .NET Compact Framework and full .NET. It's basically a Dapper clone, so it's a single file under 200 lines you can drop into your project.
I had tried OpenNETCF.ORM but found it too opinionated. I love using Dapper in my desktop apps but unfortunately it doesn't work with .NET Compact Framework.
I also built a Micro-ORM layer over the top of DapperLite to make it a bit easier to use, which is essentially a clone of Dapper.Rainbow
I have a Symbian 9.1 handset, Nokia E65, based on Nokia S60 series UI. I'd like to build a simple, full screen, graphic application. It should be able to display some text and pictures and have a basic interaction from the keyboard. That's for me only, not to be deployed.
Now, what do you think is the quickest and most painless way to have it done?
I have the following skills:
- HTML, PHP, ASP.net, JS
- ASP.net and C#, Silverlight
- Java, but mostly for networking, not UI
- Some C++
I have downloaded the Nokia IDE, but it is scary at first sight :)
Any tutorial or example are welcome!
Edit:
In particular, two questions:
is there a possibility to make a stand-alone flash application for that handset?
how about the QT mobile version?
For your device, definitely use Python for S60. It is much easier to start with than Symbian's C++ SDK and in case you ever need more low level functionality than python gives you, you can write small modules in c++ and use them in your Python program.
For a simple application like the one you are describing, Python will do just fine. You don't even need any of Nokia's IDEs / tools on the PC, you can just write the code in any text editor, copy it to the phone and test it live.
As others have mentioned, other options include:
Symbian C++ SDK : As you have discovered the tools and not the most intuitive to work with, development is not straight forward either.
Nokia's WRT : Using javascript/css/html, but it is not available for your phone.
Qt : Not available for your phone.
Java Me : Probably your second best option, your code will be slightly larger but more protable. The tools are not as straight forward as with Python, but definitely not as complicated as with Symbian.
If you think you may like to do some further development on the Symbian platform in future, I'd strongly suggest looking at Qt. Unfortunately, however, you can't use it on your E65, since Qt requires S60 3.1 or higher. (The E65 runs S60 3.0).
Since Qt coding in done in C++, you also have access to native platform APIs if required. For most apps however, the (considerably more user-friendly) Qt APIs provide all the functionality you need.
Depending on your background, the learning curve may be steeper than using Java or Python, but the pay-off is that you get access to a very powerful toolkit. And of course, as long as you use only Qt APIs, your app should be easily portable to other Qt platforms if necessary.
Go for Java ME.
All the things you list in your post is possible to do in Java.
The Symbian SDK for C++ can be downloaded here.
NSBasic is another option.
Kindness,
Dan
May I suggest Python? For newer Symbian handsets I'd recommend Web Runtime (WRT), but it is not supported on good old E65.
I'm obviously biased but I would suggest getting the 2D graphics example code from the "Quick Recipes On Symbian OS" book:
If you know HTML and JS already, you should be able to write a Web widget for your Symbian device pretty easily, using the tools available through Forum Nokia. More info here:
http://www.forum.nokia.com/Technology_Topics/Web_Technologies/Web_Runtime/
These widgets are standalone full screen applications that use the device WebKit browser engine for rendering and UI. You can also use keyboard inputs and customize the softkeys if you wish.