Circle! The Social Network of Pakistan

Another Success of AppFlute in the field of Social Networking in Pakistan. AppFlute has launched Circle.pk which is a Social Networking place where you can connect with your friends; share photos,videos and audios with friends and family; discover latest news and blogs as well.

This is a good effort in developing a platform for all the Pakistani’s to interact with each other in there on Circle which is Ad-Free platform.

User can do anything what he or she want in a Social  Network.

Advertisements

, , , ,

Leave a comment

How to include external jar file in BlackBerry Eclipse plugin

You might need to preverify the jar file. This is how you can preverify a jar file

1.Go to your JDE installation folder, for Windows XP it is usually C:\Program Files\Research In Motion\BlackBerry JDE 4.3.0\bin.

If you are using eclipse then you can also find the installation directory of BlackBerry plugin.

E:\eclipse\plugins\net.rim.eide.componentpack4.5.0_4.5.0.16\components\bin

2. Copy your jar  file to bin folder.
3. Notice the preverify.exe file. This is the tool we’ll use.
4. Now open your command prompt and change your current directory to your JDE installation directory.
5. execute the following command:
preverify -classpath “JDE_PATH_HERE\lib\net_rim_api.jar” “your_jar_filename”
6. Notice that in bin directory, another folder named output has been created. Preverified jar file resides here. Copy the preverified jar file with the same name that the non-preverified jar file has.
7. Now replace the non-preverified jar file with the verified one. Use this jar in next steps

Create a new Blackberry project with any name like LibProject.
Right-click on the project and go to Properties.
Go to Blackberry Project Properties. Click on the Application tab.
Under Project Type, change to Library.
Next, go to the Java Build Path.
go to libraries and add the jar file as an external library.
Go to Order and Export tab here, and mark your jar file as exportable
Click OK.

Build the library project.

Now, create your main BlackBerry project
Keep this projects type to as you wish it to be.
Now go to the properties of this project, In the Java Build Path, add the LibProject project as a Project dependency.

You are pretty much ready to import the jar in your code. Try to import a class and enjoy it will work 100%.

That’s all for now

Leave a comment

Is Android App security better than the iPhone?

image image

A recent article from online American magazine PC World has suggested a few reasons as to why applications available for download through the Android marketplace are more secure and less likely to cause harm or access personal information without user knowledge than those available from Apple AppStore. The 3 suggestions, in short, centre around permissions, the marketplace itself and the openness of the platform; more explanation below.

Permissions – Android is based on the Linux platform and each application runs in a separate ‘silo’ unable to read/write data or code to other applications. Each app also has a unique identifier with permissions restricting what it is capable of on the system. This is similar to the way Linux distros run on a PC with users (in this case the apps) being unable to access the full power and cause harm to the system at a whole without ‘root’ password knowledge.

Also for data to be shared across applications (e.g. accessing contact information) the user must be explicitly informed. In other words if the app is attempting to access information you think it shouldn’t, you have the option to stop the installation before any harm is done.

With the iPhone there are a number of system resources that an app can have access to by default, a rogue app could potentially be causing damage without your knowledge whereas the Android app has the ability to raise your suspicions early.

The Marketplace – Apple pride themselves on approving every app themselves before it goes to market whereas Google have faith in their user-evaluated service. While some consider Apple’s stance to be the safer, as the consumer we are unaware what checks the approval service itself actually consists of. Also updates to the app could always include malicious code. Also, security research firm Lookout found after some digging that iPhone apps were nearly twice as likely to be accessing personal contact information then Android apps.

Openness – Android isn’t as open a platform as many would like but there is no denying that it is more open than the iOS platform. The main point here is that the the underlying code of Android is open to scrutiny by users and developers across the world – meaning there are far more people who can potentially discover bugs, holes and problems with the platform and available applications than Apple could possible offer.

What are your thoughts? Have you experienced security issues with downloadable applications on either platform? And what do you think about the openness of Android over the closed approach of Apple? Is user-centric evaluation important to you?

Reference: http://blog.clove.co.uk/2010/08/27/is-android-app-security-better-than-the-iphone/

Leave a comment

OOPS Interview Questions and Answers

1) What is meant by Object Oriented Programming?
OOP is a method of programming in which programs are organised as cooperative collections of objects. Each object is an instance of a class and each class belong to a hierarchy.

2) What is a Class?
Class is a template for a set of objects that share a common structure and a common behaviour.

3) What is an Object?
Object is an instance of a class. It has state,behaviour and identity. It is also called as an instance of a class.

4) What is an Instance?
An instance has state, behaviour and identity. The structure and behaviour of similar classes are defined in their common class. An instance is also called as an object.

5) What are the core OOP’s concepts?
Abstraction, Encapsulation,Inheritance and Polymorphism are the core OOP’s concepts.

6) What is meant by abstraction?
Abstraction defines the essential characteristics of an object that distinguish it from all other kinds of objects. Abstraction provides crisply-defined conceptual boundaries relative to the perspective of the viewer. Its the process of focussing on the essential characteristics of an object. Abstraction is one of the fundamental elements of the object model.

7) What is meant by Encapsulation?
Encapsulation is the process of compartmentalising the elements of an abtraction that defines the structure and behaviour. Encapsulation helps to separate the contractual interface of an abstraction and implementation.

8) What is meant by Inheritance?
Inheritance is a relationship among classes, wherein one class shares the structure or behaviour defined in another class. This is called Single Inheritance. If a class shares the structure or behaviour from multiple classes, then it is called Multiple Inheritance. Inheritance defines “is-a” hierarchy among classes in which one subclass inherits from one or more generalised superclasses.

9) What is meant by Polymorphism?
Polymorphism literally means taking more than one form. Polymorphism is a characteristic of being able to assign a different behavior or value in a subclass, to something that was declared in a parent class.

10) What is an Abstract Class?
Abstract class is a class that has no instances. An abstract class is written with the expectation that its concrete subclasses will add to its structure and behaviour, typically by implementing its abstract operations.

11) What is an Interface?
Interface is an outside view of a class or object which emphaizes its abstraction while hiding its structure and secrets of its behaviour.

12) What is a base class?
Base class is the most generalised class in a class structure. Most applications have such root classes. In Java, Object is the base class for all classes.

13) What is a subclass?
Subclass is a class that inherits from one or more classes

14) What is a superclass?
superclass is a class from which another class inherits.

15) What is a constructor?
Constructor is an operation that creates an object and/or initialises its state.

16) What is a destructor?
Destructor is an operation that frees the state of an object and/or destroys the object itself. In Java, there is no concept of destructors. Its taken care by the JVM.

17) What is meant by Binding?
Binding denotes association of a name with a class.

18) What is meant by static binding?
Static binding is a binding in which the class association is made during compile time. This is also called as Early binding.

19) What is meant by Dynamic binding?
Dynamic binding is a binding in which the class association is not made until the object is created at execution time. It is also called as Late binding.

20) Define Modularity?
Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.

21) What is meant by Persistence?
Persistence is the property of an object by which its existence transcends space and time.

22) What is colloboration?
Colloboration is a process whereby several objects cooperate to provide some higher level behaviour.

23) In Java, How to make an object completely encapsulated?
All the instance variables should be declared as private and public getter and setter methods should be provided for accessing the instance variables.

24) How is polymorphism acheived in java?
Inheritance, Overloading and Overriding are used to acheive Polymorphism in java.

Leave a comment

Are You a Software Architect?

By Simon Brown on Feb 09, 2010

The line between software development and software architecture is a tricky one. Some people will tell you that it doesn’t exist and that architecture is simply an extension of the design process undertaken by developers. Others will make out it’s a massive gaping chasm that can only be crossed by lofty developers who believe you must always abstract your abstractions and not get bogged down by those pesky implementation details. As always, there’s a pragmatic balance somewhere in the middle, but it does raise the interesting question of how you move from one to the other.

Some of the key factors that are often used to differentiate software architecture from software design and development include an increase in scale, an increase in the level of abstraction and an increase in the significance of making the right design decisions. Software architecture is all about having a holistic view and seeing the bigger picture to understand how the software system works as a whole. While this may help to differentiate software development and software architecture, it doesn’t necessarily help to understand how somebody moves from development into architecture. Furthermore, it also doesn’t help in identifying who will make a good software architect, how you go about finding them if you’re hiring and whether you are a software architect.

Experience is a good gauge but you need to look deeper

Becoming a software architect isn’t something that simply happens overnight or with a promotion. It’s a role, not a rank. It’s an evolutionary process where you’ll gradually gain the experience and confidence that you need to undertake the role.

There are a number of different qualities that you can look for in a software architect and their past experience is often a good gauge of their ability to undertake the role. Since the role of a software architect is varied though, you need to look deeper to understand the level of involvement, influence, leadership and responsibility that has been demonstrated across a number of different areas. Broadly speaking, the software architecture on most projects can be broken down into two phases; the architecture is defined and then it’s delivered.

Definition of the software architecture

The architecture definition process seems fairly straightforward. All you have to do is figure out what the requirements are and design a system that satisfies them. But in reality it’s not that simple and the software architecture role can vary wildly depending on how engaged you are and how seriously you view your role. As the following diagram shows, the architecture definition part of the role can be broken down further into a number of different elements.

The role of a hands-on software architect from a definition perspective

  1. Management of non-functional requirements: Software projects often get caught up on asking users what features they want, but rarely ask them what non-functional requirements (or system qualities) they need. Sometimes the stakeholders will tell us that “the system must be fast”, but that’s far too subjective. Non-functional requirements need to be specific, measurable, achievable and testable if we are going to satisfy them. Most of the non-functional requirements are technical in nature and often have a huge influence on the software architecture. Understanding the non-functional requirements is a crucial part of the role, but there’s a difference between assuming what those requirements are and challenging them. After all, how many systems have you seen that genuinely need to be operational 24×7?
    Management of non-functional requirements
  2. Architecture definition: With the non-functional requirements captured, the next step is to start thinking about how you’re going to solve the problems set out by the stakeholders and define the architecture. It’s fair to say that every software system has an architecture, but not every software system has a defined architecture. And that’s really the point here. The architecture definition process lets you think about how you’re going to take the requirements along with any imposed constraints and solve the problem. Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project. Defining architecture is your job as a software architect but there’s a big difference between designing a software system from scratch and extending an existing one.
    Architecture definition
  3. Technology selection: Technology selection is typically a fun exercise but it does have its fair set of challenges when you look at cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments and so on. The sum of these factors can often make a simple task of choosing something like a rich client technology into a complete nightmare. And then there’s the question of whether the technologies actually work. Technology selection is all about managing risk; reducing risk where there is high complexity or uncertainty and introducing risk where there are benefits to be had. Technology decisions need to be made by taking all factors into account, and all technology decisions need to be reviewed and evaluated. This includes the major building blocks for a software project right down to the libraries and frameworks being introduced during the development. If you’re defining an architecture, you also need to be confident that the technology choices being made are the right choices. Again there’s a big difference between evaluating technology for a new system versus adding technology into an existing system.
    Technology selection
  4. Architecture evaluation: If you’re designing software, you need to ask yourself whether your architecture will work. For me, an architecture works if it satisfies the non-functional requirements, provides the necessary foundation for the rest of the code and provides a sufficient platform for solving the underlying business problem. One of the biggest problems with software is that it’s complex and abstract, which makes it hard to visualise the runtime characteristics from UML diagrams or the code itself. We undertake a number of different types of testing throughout the software development lifecycle to give us confidence that the system we are delivering will work when rolled out. So why don’t we do the same for our architectures? If you can test your architecture, then you can prove that it works. And if you can do this as early as possible, you can reduce the overall risk of project failure rather than simply hoping for the best.
    Architecture evaluation
  5. Architecture collaboration: It’s unusual for any software system to live in isolation and there are a number of people that need to understand it. This ranges from the immediate development team who need to understand and buy in to the architecture, right through to other stakeholders who have an interest from a security, database, operations, maintenance, support, etc point of view. For a software project to be successful, you need to collaborate closely with all of the system stakeholders to ensure that the architecture will successfully integrate with its environment. Unfortunately, architecture collaboration within the development team seldom happens, let alone the external stakeholders.
    Architecture collaboration

Delivery of the software architecture

It’s the same story with architecture delivery too, where the software architecture role can vary depending on the level of engagement across the elements that contribute to a successful software project.

The role of a hands-on software architect from a delivery perspective

  1. Ownership of the bigger picture: In order to carry the architecture through to a successful conclusion, it’s important that somebody owns the big picture and sells the vision throughout the entirety of the software development lifecycle, evolving it throughout the project if necessary and taking responsibility for ensuring that it’s delivered successfully. If you’ve defined an architecture, it makes sense to remain continually engaged and evolve your architecture rather than choosing to hand it off to an “implementation team”.
    Ownership of the bigger picture
  2. Leadership: Owning the bigger picture is one aspect of technical leadership, but there are other things that need to be done during the delivery phase of a software project. These include taking responsibility, providing technical guidance, making technical decisions and having the authority to make those decisions. As the architect, you need to undertake the technical leadership to ensure everything is taken care of and that the team is being steered in the right direction on a continuous basis. The software architect position is inherently about leadership and while this sounds obvious, many project teams don’t get the technical leadership that they need, with architects assuming that a successful delivery isn’t necessarily their problem.
    Leadership
  3. Coaching and mentoring: Coaching and mentoring is an overlooked activity on most software development projects, with many team members not getting the support that they need. While technical leadership is about steering the project as a whole, there are times when individuals need assistance. In addition to this, coaching and mentoring provides a way to enhance people’s skills and to help them improve their own careers. This is something that should fall squarely within the remit of the software architect, and clearly there’s a big difference between coaching your team in architecture and design versus helping them with their coding problems.
    Architecture delivery
  4. Quality assurance: Even with the best architecture and leadership in the world, poor delivery can cause an otherwise successful project to fail. Quality assurance is a large part of an architect’s role, but it’s more than just doing code reviews. For example, you need a baseline to assure against, and this means the introduction of standards and working practices. From a software development perspective, these could include coding standards, design principles and source code analysis tools through to the use of continuous integration, automated unit testing and code coverage tools. It’s safe to say that most projects don’t do enough quality assurance, and therefore you need to figure out what’s important and make sure that it’s sufficiently assured. For me, the important parts of a project are anything that is architecturally significant, business critical, complex or highly visible. You just need to be pragmatic and realise that you can’t necessarily assure everything, doing something rather than doing nothing.
    Quality assurance
  5. Design, development and testing: The last thing that falls squarely within the role of a software architect is design, development and testing. Being a hands-on architect doesn’t necessarily mean that you have to get involved in the day-to-day coding tasks, but it does mean that you’re continuously engaged in the project, actively helping to shape and deliver it. Having said that, why shouldn’t the day-to-day coding activities be a part of an architect’s role? Most architects are experienced coders, so it makes sense to keep those skills up-to-date. In addition, the architect can experience the same pain as everybody else on the team, which in turn helps them better understand how their architecture is viewed from a development perspective. Many companies have policies that prevent software architects from engaging in coding activities because their architects are “too valuable to undertake that commodity work”. Clearly this is the wrong attitude … why let your architects put all that effort into defining the architecture if you’re not going to let them contribute to its successful delivery? Of course, there are situations where it’s not practical to get involved at the code level. For example, a large project generally means a bigger “big picture” to take care of and there may be times when you just don’t have the time. But generally speaking, an architect that codes is more effective and happier than an architect that watches from the sidelines.
    Design, development and testing

Are you a software architect?

Regardless of whether you view the line between software development and architecture as mythical or a gaping chasm, the elements above highlight that people’s level of experience across the software architecture role varies considerably depending on how engaged they are and how seriously they view their role. Most developers don’t wake up on a Monday morning and declare themselves to be a software architect. I certainly didn’t and my route into software architecture was very much an evolutionary process. Having said that though, there’s a high probability that those same developers are already undertaking parts of the software architecture role, irrespective of their job title.

There’s a big difference between contributing to the architecture of a software system and being responsible for defining it yourself; with a continuum of skills, knowledge and experience needed across the different areas that make up the software architecture role. Crossing the line between software developer and software architect is up to you, but understanding your own level of experience is the first part of the journey.

Reference: http://www.infoq.com/articles/brown-are-you-a-software-architect

Leave a comment

The role of the Software Architect by Fabrice Marguerie

The Software Architect function is not well defined, and we have to admit that it is difficult to give a precise definition of the term. This article tries to determine the identity of these strange characters by presenting the tasks they are assigned and the required qualities to fulfill them.

Some time ago, I was asked to give my definition of the role of a software architect in a small team, and state what the required qualities to satisfy this function are, in my opinion. This article presents the answer I gave at that time. I hope it will help you to better understand the role and duties of an architect.

Architect or ArchitectS ?

The term “Software Architect” is somewhat vague. The definitions we can give depend on the context. This article concentrates on architects working with a small to medium team, on multiple projects, but not so many. In these conditions, the software architect also acts as a technical expert on one or multiple platforms.

During the DotNetGuru Symposium 2003, Sami Jaber presented two kinds of architects:

  • functional architects, who optimize business processes, and have a very good knowledge about analysis methods;
  • technical architects, who design long-term, reliable and adaptive technical architectures, and constitute a technical gateway between the project manager and the developers.

//
//

We can come across other kinds of architects. You can refer to the resources presented at the bottom of this page to learn more. We will focus here on technical architects, and not on functional architects.

Here is the role of a technical architect, according to Sami:

  • Anticipate on technological evolutions
  • Build durable architectures
    • Independence with regard to API/framework providers
  • Promote genericity and abstraction
  • Bridge between developers, project managers, and business experts
  • Technological evangelization, sharp sense of communication
  • Ensure the technical directions and choices
  • Often mixed culture (.NET/J2EE/opensource)
  • First a role instead of a job

Tasks and required skills

I won’t give here a definition of the word architect in the sense I use it. I will instead introduce some aspects of the role of a technical software architect, as well as the required qualities to perform such a function. As previously stated, I here address mostly the context of small and medium-sized businesses or small development departments. In these cases, the role is often close to the role of a technical expert.

We could summarize the functions of an architect within a few words. Those could include: proposal work, advisory work, design, realization, validation, presentations, reports, management, transmitting as clearly as possible the results of a continuous technological survey, guarantee the technical quality of developments…
But there is much more than that. The work carried out by an architect is satisfying only if he has understood that his mission goes beyond simple expertise and knowledge application.

An architect is often an ex-developer who has accumulated such experience as to reach a good level in expertise. This experience must cover ideally a variety of platforms and products, and knowledge about the lifecycle of an application, or even of an information system.

The role of an architect is unique compared to the job of developers or project managers, because it requires long-term involvement, transverse to projects and teams. This gets even truer for long-lasting collaborations, compared to classic consulting missions.
It is a key role in a team. The architect must work hand in hand with the whole of the team to federate the energies of all the team members.

It is obvious that the benefits of having an architect highly rely on his involvement and integration with the project teams. It is thanks to permanent interchanges with the developers and the project managers that the architect will be able to communicate his knowledge, but also make the best out of the work of the team and the individuals. The architect must also be listening to the needs. Due to all this, there are big relational requirements in this function. Communication skills are required.
Diplomacy and pedagogy skills are also required to be able to explain architectures, debate about them and have them adopted.

An architect must be able to step back and take a higher-level look, which is often difficult for developers and projects managers because they are often too focused on a specific project and so on immediate needs. This means raising from the application level to the information system level. This also means that the architect has to perform a continuous technological survey; one that goes further than the context a specific project.

The architect has to submit proposals on the directions for developments, with a long-term vision of the information system’s architecture and of application integration problems, while keeping in mind the priorities. It is thus better to favor a pragmatic approach, by opposition to an idealistic one. Theory must remain guidance for the long term and not an obstacle for developments, which are often constrained in terms of delays.
However, even if I maintain that an architect has to step back from his work and the teams’ work, I hardly conceive an architect who would remain far from the implementation shop (the code, the project). Indeed, an architect can have to write lines of code (at least to create prototypes or mock-ups), but also has to get his hands dirty with code to validate the quality of what is produced or resolve a particularly technically difficult situation. Often are the pretty UML diagrams or the architecture papers to be left aside to look under the hood how things work (or don’t) in an application. This mainly means that an architect must be able to quickly read and analyze code.

An architect doesn’t take part to a project only at its beginning, but during the whole project’s lifecycle to ensure a right implementation of the design and architecture. He also has to keep listening to new requirements to adapt solutions if needed. Therefore, the involvement of an architect can span the lifetime of an application to give new directions, and ensure that the evolutions don’t weaken the whole construction.

Often, architects will initiate in-house frameworks, which represent a big part of the capitalization work of a company. In this case, the architect becomes responsible for the framework’s directions and works on the evolution to come.
A framework also facilitates the adoption of a technological platform such as .NET or J2EE. This is another task where an architect can help if he is expert in a given environment.

Let’s repeat that architect is more a role than a job. Having experience is not all, it also requires qualities and before all a state of mind.

Architect or developer?

To finish on a lighter note, a question that gets often asked is: “how to differenciate a software architect from a developer?” Michael Platt wrote: “Architects are a lot slower in getting a solution, especially if the problem is simple!”. Probably we could add that “Architects are much likely to come up with complex and costly solutions, especially if the problem is simple!”.

Addendum

When I first published this article, a couple of persons came up with interesting links:

Reference : http://madgeek.com/Articles/Architect/EN/architect.htm

Leave a comment

Steps to create Andriod Widget

In this article will help us to create customized Widget.

1. Create a Layout for Widget
2. Create Widget Class
3. Adding the Widget Provider Info Metadata
4. Register the Widget in Androidmanifest.xml
5. Add the Widget in your homepage

Create a Layout for Widget
<?xml version=”1.0″ encoding=”utf-8″?>
<LinearLayout xmlns:android=”http://schemas.android.com/apk/res/android&#8221;
android:orientation=”vertical” android:layout_width=”fill_parent”
android:layout_height=”fill_parent” android:background=”@drawable/widget_bg”>
<Button android:text=”Click” android:id=”@+id/Button01″
android:layout_width=”wrap_content” android:layout_height=”wrap_content”></Button>

<TextView android:id=”@+id/text” android:layout_width=”fill_parent”
android:layout_height=”fill_parent” android:text=”@string/hello”
android:gravity=”center” android:textColor=”@android:color/black” />
</LinearLayout>

Create Widget Class
public class Widget extends AppWidgetProvider {
private SimpleDateFormat formatter = new SimpleDateFormat(
“EEE, d MMM yyyy\nHH:mm:ss.SSS”);

@Override
public void onUpdate(Context context, AppWidgetManager appWidgetManager,
int[] appWidgetIds) {

String now = formatter.format(new Date());

Intent intent = new Intent(context, MainActivity.class);
PendingIntent pendingIntent = PendingIntent.getActivity(context, 0,intent, 0);

RemoteViews updateViews = new RemoteViews(context.getPackageName(),R.layout.main);
updateViews.setTextViewText(R.id.text, now);
appWidgetManager.updateAppWidget(appWidgetIds, updateViews);

RemoteViews views = new RemoteViews(context.getPackageName(),R.layout.main);
views.setOnClickPendingIntent(R.id.Button01, pendingIntent);
appWidgetManager.updateAppWidget(appWidgetIds, views);

super.onUpdate(context, appWidgetManager, appWidgetIds);

}
}

Adding the Widget Provider Info Metadata

<?xml version=”1.0″ encoding=”utf-8″?>
<appwidget-provider xmlns:android=”http://schemas.android.com/apk/res/android&#8221;
android:minWidth=”166dip” android:minHeight=”72dip” android:updatePeriodMillis=”60000″ android:initialLayout=”@layout/main” />

Register the Widget in Androidmanifest.xml

<receiver android:label=”@string/widget_name” android:name=”.Widget”>
<intent-filter>
<action android:name=”android.appwidget.action.APPWIDGET_UPDATE” />
</intent-filter>
<meta-data android:name=”android.appwidget.provider” android:resource=”@xml/widget” />
</receiver>

Add the Widget in your homepage
Click Menu -> Add -> Widget -> YOUR WIDGET

Reference: http://about-android.blogspot.com/2010/05/steps-to-create-andriod-widget.html

Leave a comment