It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am creating an application in Windows OS using WPF (C# as code behind) with the data stored in the Unix machine which is in the same network. My app needs a way to communicate with the Unix machine to get the data from it and show it on windows UI (created in WPF).
My app will also need to know all the Unix machines connected in the network via broadcasting.
What is the best way to connect to Unix machines with my WPF application for the above mentioned requirements?
If the data you want to use is file based, you could use an ftp or samba servers on unix. One of the advantages of samba server is that it has an ability to broadcast and allows discovering of its resources in the network through netbios. This will comply with your broadcasting requirement.
If file based storage is not enough, consider a web service. Since you are writing an application in .NET it will be easiest for you to use Mono on the Unix side. You can write a web service in Mono http://www.mono-project.com/Writing_a_WebService that will listen to requests from your WPF application.
I admit that this solution is not the best in terms of performance, scalability and portability, but it's the quickest for a .net developer.
The other requirement concerning that your app needs to know the list of unix machines is more complicated. Brute force approach would be to have a master server that will listen for notifications from unix machines when they come to life. It will give that list to the WPF client.
If you want to go for a more performing, portable solution and you have more development resources, you can implement a restful service on the unix side with one of these frameworks REST frameworks
The most complex approach in terms of development time is to use bare TCP ip. That will require a lot of coding on both client and server sides and a long process of making it stable. Again it depends on how complex your data interaction is going to be.
"with the data stored in the Unix machine which is in the same network" assuming you mean it is in a database I would recommend some sort of ORM (like NHibernate)
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I would like to customize the login screen in a Linux OS. Not just the bacground image, but everything from buttons to textboxes, even the login method (so not a username + password, but something of my own).
The flavor of Linux doesn't really matter, it only needs to have a graphical interface. I have some experience with Ubuntu though.
However, this would be my first time developing something for Linux -- I have developed applications for Windows before, mostly in C# -- but I am up to the challange to learn something new. So please try to be a bit easier on me, me being something of a noob at the moment.
So, how can I do this?
The "login screen" shown on GNU/Linux systems to login to a graphical session is part of the desktop environment you are using. Various alternatives exist for the zoo of alternative environments out there. Examples are kdm as offered by the KDE desktop environment, gdm as offered by Gnome, xdm, wdm, many others exist. Start by reading the wikipedia article about kdm to get an impression.
You'd have to implement a replacement for that part which serves the same purpose, if the existing options to configure it are not enough. So best probably is to start reading about those. That should give you an impression about the requirements.
Roughly explained you have to create an executable that can be executed by the system and configure that as "desktop manager" in the systems configuration. The exact location of that configuration again depends on the distribution, but the general approach always is the same.
The logic of such a program has to somehow answer the question of whether a user is allowed to login to the system by whatever means chosen. Typically this is done by using PAM in background ("Pluggable authentication modules"). Maybe start by reading an introduction to PAM to gain insight into how things work, which may be a bit confusing at first glance due to its endless flexibility. That framework is used on modern unixoid systems to separate the requirements for that logic from the actual implementation. So you really want to learn about how PAM works too. It is an unbelievable flexible framework where already endless strategies exist, so countless adapters for all sorts of existing authorities like databases, LDAP servers, simple file based authorities, IMAP servers, you name it: everything you can imagine. So chances are that you do not have to implement anything, but just can pick something implemented by someone else and configure / tailor it to your needs.
The logic itself does not have to be complex, it just has to answer that simple question in an clear way: is the user who requests access granted or not. For that it will (or will not) have to consult some existing authority. How exactly that works obviously is completely up to you. The real difficult thing probably is to access and control the graphics hardware without having a running graphical desktop environment to build on (since that is only started afterwards). So you probably have to deal with some hardware abstraction layer. Which again means that you probably want to be using some language like C or C++ for that job, scripting languages are less well suited for such job, also because they introduce all sorts of additional requirements of what has to be installed on a system which becomes unusable if some element inside that chain of utilities break due to the lack of a login screen :-)
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm starting to architect a new Windows application that will require a fairly rich client interface, but I have no idea what client API I should go with (WPF, Silverlight, WinRT, HTML5, other?). I'm actually rather disturbed that there is so little guidance from MS to help people make this decision.
Whats the MS support strategy for the different client APIs? Whats the longevity for each? I dont want to write a full client application in a currently known and supported API (WinForms or WPF) only to have MS pull support for it in two years, and be forced to re-write it. But I really cant write it in WinRT because mass corporate deployment wont be in place for at least 2 years. So am I forced to go with a web based approach, like Silverlight instead? Whats its support/longevity story? Do I go HTML5 instead? If I go that route, whats the benefit of using the Microsoft stack instead of just going the open source stack?
It feels like I'm in a total catch 22 here, and I cant find any good guidance from Microsoft. From the sounds of things it would be stupid to write software in WPF because its being dropped (soon?), but I cant write it in WinRT because corporations wont deploy it for a couple years. This whole thing just feels completely skitsofrantic to me.
Thoughts or ideas?
Taking your experience into account, and also the fact that you said 'Windows Application' (not web application) I would definitely go with WPF. Keep in mind that regardless of using a different set of underlying APIs, WinRT still keeps the core concepts of WPF: XAML, Bindings, Styles, Triggers, DataTemplates and so on. So, while it is true that you cannot copypaste code from WPF to WinRT and press F5, there is a significant amount of work that would be compatible between these technologies (namely ViewModels that are view-agnostic), while HTML, Winforms and other frameworks have completely different ways of doing things, and require a different mindset to work with.
In regards of what will Microsoft do.. I wouldn't be too worried, because evidence shows that even older technologies such as VB6 still remain "runnable" in current versions of OSes, and I don't think there will be a need to rewrite the whole application in 2 years even if Metro becomes a standard. Metro cannot replace desktop traditional applications, which still prove to be the best option for data intensive applications.
And, if it ever comes the time when all of us are really pushed into WinRT, it's gonna be immensely easier for those who made SL / WPF applications already written using MVVM and XAML, than for those who did HTML or winforms.
Whatever you end up choosing, make sure you separate as much as possible your application's functionality from the UI. This will definitely make it a lot easier when a UI framework change is required.
This is just my personal opinion, and I would like to hear what other people have to say about this subject too.
Edit: Another really important aspect is that if you need to really make an animation-intensive UI, or take a step away from traditional battleship-gray UIs, you're gonna end up suffering a lot from winforms incapabilities on this, or HTML/Javascript hell where all browsers render things differently, not to mention the amount of code required in these technologies to achieve things that require 3 lines of XAML in WPF / SL / WinRT.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
We're the developers of a relatively complex non-game iPhone 3 application, and we're beginning an ambitious rewrite to take better advantage of iOS 4. There's a significant social element to the app, so we started thinking that we'd like to make it available on as many modern mobile platforms as possible:
iPhone/iOS
Android
Windows Phone
BlackBerry OS
Symbian
There are several approaches to cross-platform development, and they all have limitations. No solution manages to take advantage of all a device's functionality the way a native application can. Given the complexity of our app, I'd simply like to maximize "logical" code reuse without resorting to a cross-platform framework. I'm envisioning tools that will make developing and testing apps against multiple platforms a little more seamless. What can we do to make developing on 5 platforms take less than 5 times the effort?
Push as much of the functionality as you can back to a shared web server, and try to make only the UI specific to the platform.
I know you said no cross-platform frameworks, but perhaps something to look at:
Write all the core logic in javascript. Unit test that at will. Then use tools like Appcelerator to turn that logic into native code.
Then import that logic code into your native platform projects for each of those platforms, and build out the other features you feel can't be achieved properly in any other way.
For platforms they don't support right now, you might be able to find a js to native code converter, or indeed a way of hosting a js environment within those platforms.
None of these will play nice together. It's not in their perceived best interest to do so.
The best bet is to dumb everything down and keep it simple. Simplicity always wins when you are trying to sandbox multiple hostile interests.
Look to XML for all data, and then have 5 binaries to read it or push it all to a web server via PHP. All these mobile platforms will function nicely with XML because it's in their best interest to do so. Worry about branding and appearances AFTER you get the core functionality off the ground.
NOTE: Javascript is the last thing you should be looking at in the beginning. It rarely plays nicely on all platforms in the same way. So make sure that your JS layer is independent of your data layer. DO NOT INTEGRATE THEM. That would be bad. You want your Android JS to be potentially different than the JS you push on the Blackberry for example. Because you won't know how quirky it will end up being until you try it out and test your methods.
I agree with Beth. I have developed a product based on the same thought process. I have a java server running on a socket, which has a client library that client app's use to connect to the server. The client abstracts out the socket piece and provides easy api's for client apps to call.
The server is equipped to handle multiple client connections in parallel, thread pool concept.
Now, since it will be a java client library, you can only run this on android. To get this working on other platforms, you can run this client piece on J2EE. This way you create a third middle layer. All other platforms can then connect using the browser.
With this done, you can now use JSON to Object libraries to expose your object (on the server side) to JSON. I haven't done this yet, but will do it in a few weeks.
Btw, I just cant get myself to use any cross platform frameworks. They promise the world, and dont mention any of their limitations upfront. Its painful towards the end of your product/app release to find out all these limitations/hidden costs.
Well, you can look at JQTouch, SensaTouch or maybe wait for a while to see the jqueryformobile to finally get published. If you are not in a hurry, I would already start working in jQuery, since two out of three from this list are (will be) based on jQuery as plugins
I'm currently thinking to this problem , and my solution would be to put all the logic server side and use an approach like Model-View-Presentation, a series of events fired by the UI that should instead be specific for the client
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
After Silverlight 4.0 has been released with new WPF, I am kind of confused with these technologies: Silverlight? WPF? Windows Form?
The main motive that we want to achieve for BIG business project is following:
Performance
Security
And platform independent**
If I consider all above three points then only Silverlight is the option as I don’t want people buying emulator on MacOS for WPF or Windows Form.
Now how good the Silverlight is for Business applications, I was completely against when Silverlight 2.0 was in the market but now it is Silverlight 4.0 and they have provided many new features (but still basics) that is required in any challenging business
applications.
Comparing Silverlight and WPF
-* Silverlight and WPF are very new technology and if I'd to compare from these two then I'd prefer WPF because it can be considered stable and mature. But it is not same as Windows Form.
-* If I go with Silverlight then I am sure about keep updating to the latest version of Silverlight. I remembered when we were developing software for version 2.0 then we'd to create our own framework with dynamic loading DLL, and then Navigation concept. But everything was got changed once Silverlight 3.0 came. I don't want this to be happening with this new product.
-* If we go with WPF then we don't get the platform independence.
Now, why not we just focus on making WPF and then move to Silverlght. As someone (Tim?) from Microsoft has said that the idea is to make Silverlight as close as WPF. But if that is the case then why XAML structure is different; I will not be convinced with by saying that .Net framework for SL is too small.. well the difference is coming from the namespace ?
I was searching on this subject and found "Microsoft WPF-Silverlight Comparison Whitepaper v1.1.pdf". This guide is very good that gives you ins-outs about how can we build common apps that runs on both. But again, it is comparing Silverlight 2 and not 4.
I am sure many architect/ developers/ project managers must be facing similar kind of questions in their premises and wants to initiate this discussion, if it has not been :).
We've still got 2 weeks to make this decision, so I'm expecting everyone to participate, gurus?
All three of the technologies can be made both performant and secure, depending on your definition of those terms. Of the three, only Silverlight is really cross-platform. However, I'd have to wonder about the finer detail of your requirements before I could make any kind of informed decision...
Performance is an important consideration. What part of your application are you expecting to be a performance problem, and why? Knowing this helps you understand how the technologies might solve the problem.
Security could mean anything. Do you have data that you need to secure? Does the application itself have to run in a privileged environment? Is it a multi-user application, a networked application, an application that is likely to cache data client-side, etc... You really can't dismiss any of the technologies for being "insecure" - unless you can more tightly define what your vision of security is.
What level of cross platform support do you really need? How much are you willing to spend to achieve it? Most businesses say they want to support multiple platforms, but the cost is often prohibitive. If you're insisting on a .NET project then I'd wager that either your technical department or your business managers aren't really committed to cross-platform and it's not really going to happen. So, do you mean "Windows XP/Vista/7", or do you mean "Windows/Mac/Linux?"
Anyone can throw an opinion on here on some generic aspect of the three technologies, but there's really no clear answer unless you have much more detailed requirements to work with.
Silverlight has become a much more mature platform since version 2.0 and has been used in anger in several large applications including the last Olympics and the WorldWide Telescope Web Client, you can search online for more case studies.
For Business applications with Silverlight 4.0 and VS2010 there is a Silverlight Business Application Template you can use to give you a head start, here is a walkthrough: http://msdn.microsoft.com/en-us/library/ee707360%28VS.91%29.aspx
Silverlight is also the only one of the three technologies in your title that is supported on an OS other than Windows (it's supported on the Mac and via Mono on Linux) so I'd say overall it's the best fit for your requirements.
Silverlight is still a web technology, so it does have some of the constraint you can have with normal web application, so if that is a show-stopper, then go for WPF. As for Windows Forms, I'm pretty sure it will live on for quite a while, but WPF and silverlight are usually better to my opinion.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
Has anyone got experience with the white framework?
www.codeplex.com/white ?
I'm thinking about using it for the next project for basic smoke tests of our windows client. I'd like some advice on articles or your own experiences. Thanks.
I recently used white to build a few (20+) UI tests for a fairly complex WinForms app with plenty of UserControls, dynamically created and 3rd-party controls.
Here are my impressions:
Very easy and intuitive to work with.
Little or no quality issues.
It's a young project so there are
some missing features, but they've
got the basics covered.
Occasionally, if a control didn't have a known AutomationID, I was forced to use keystrokes to navigate to and manipulate a control ("tab, tab, enter" for example) which was kind of a bummer, but still very easy to do in white. This usually only happened with 3rd-party or dynamically generated controls.
White's recorder is helpful (and will actually generate code for you) but does often get confused by complicated or unusual controls. For that reason I'd recommend that you...
...keep UISpy nearby so you can see the AutomationID of the controls you're working with.
And finally, if you're like me, you're hoping to set up some automated tests. This can be tricky since an automated test will usually be run by a CI tool such as CruiseControl which runs as a Windows service, which therefore has no active graphical environment (Windows session)...which white requires. The suggested way around this is to use a virtual machine. This is where I lost steam, as my tool chain had just grown too large for my purposes: CruiseControl->NAnt->NUnit->white + virtual machine.
Anyway, hope that's useful.
I evaluated it recently, but had to reject it because it would not support the third party controls (janus grid) we were using.