micromax canvas hd lollipop update
I rewrite this tutorial from forum.xda-developers.com : The users of Micromax A116 Canvas Hd can now update their handsets to Android 5.0 Lo...
-
Now You Can Link Java And Microsoft Bitlocker
Theory
In This Tutorial We Are Going To Show you How You Can Link Java And Microsoft Bitlocker Utility. The Principle We Are Working On Is That we Can get The Permutations Of A Single Word and Then Check if The word matches the password. If it Does so Then Our Program Is Able To Hack The Windows Bitlocker Password
The Underlying Code Will Show You How To Get The Permutations Of A singe Word
public class Permutation{ public static void main(String args[]){ String st = "Word Here"; TreeSet<Character> chars = new TreeSet<Character>(); for(int i=0;i<st.length();++i){ chars.add(st.charAt(i)); } int permutation =(int)Math.pow(chars.size(),st.length()); Random r = new Random(); String str =""; TreeSet<String> words = new TreeSet<String>(); outer : for(;;){ str=""; for(int i=0;i<st.length();++i){ str=str+""+chars.get(r.nextInt(chars.size())); } words.add(str); if(words.size()==permutation){ break outer; } } System.out.println("Permutations = "+words); } }The Next Part That Follows is The Linking Between Java And Microsoft BitLocker
This Part Is Quite Simple as We Have To Only Use Java And Connect That With Command Prompt The UnderLying Code Will Make A Connection Between The Twopublic class Connect { public static void main(String args[]){ Runtime rt = Runtime.getRuntime(); try{ String command ="help"; Process ps = rt.exec("cmd /c "+command); InputStream is = ps.getInputStream(); InputStreamReader rd = new InputStreamReader(is); BufferedReader br = new BufferedReader(rd); String st =""; while((st = br.readLine())!=null){ System.out.println(st); } br.close(); }catch(Exception e){ System.out.println(e.getMessage()); } } }The Above Code You see Has Been Showing The Output For "HELP" Command Of Windows Command Prompt
You May use The Following Command And See The magic
Command =manage-bde -unlock *DRIVE LETTER* -pw "the Word You Get From The Permutation Code"
This Was Just A Tutorial. Keep Your eye On The Blog for Future Posts.
Dedicated To Mr.Tony Stark -
Design Patterns in Java
One of the unchanging facts of life is that change is the undying constant in every software lifecycle - one that you cannot run away from. The challenge is to adapt to this change with minimum latency and maximum flexibility.The good news is that someone has probably already solved your design problems and their solutions have evolved into best practices; these agreed-upon best practices are referred to as "Design Patterns". Today, we're going to explore two popular design patterns, and learn how good design can help you write code that is squeaky clean and extensible.The Adapter Design Pattern
Let's assume that you have an existing legacy system. You're now tasked with making it work with a new third-party library, but this library has a different API compared to the last one you were using. The legacy system now expects a different interface than what the new library provides. Of course, you could be brave (read, foolish) enough to think about changing your legacy code to adapt to new interface but as with every legacy system -- never, ever.
Adapters to the rescue! Simply write anadapter(a new wrapping class) in between the systems, which listens for client requests to the older interface, and redirects or translates them into calls to the new interface. This conversion can either be implemented with inheritance or composition.Great design is not just about re-usability, but about extensibility.Adapters help incompatible classes work together by taking an interface and adapting it to one that the client can parse.
Adapters In Action
Enough chit-chat; let's get down to business, shall we? Our legacy software system uses the followingLegacyVideoControllerinterface to control the video system.01020304050607080910publicinterfaceLegacyVideoController{/*** Begins the playback after startTimeTicks* from the beginning of the video* @param startTimeTicks time in milliseconds*/publicvoidstartPlayback(longstartTimeTicks);...}The client code which uses this controller looks like:12345publicvoidplayBackVideo(longtimeToStart, LegacyVideoController controller){if(controller!=null){controller.startPlayback(timeToStart);}}User Requirements Change!
There's nothing new here, really - it happens quite frequently. User requirements are prone to change all the time and our legacy system now needs to work with a new video controller, having the following interface:01020304050607080910111213publicinterfaceAdvancedVideoController{/*** Places the controller head after time* from the beginning of the track* @param time time defines how much seek is required*/publicvoidseek(Time time);/*** Plays the track*/publicvoidplay();}As a result, the client code breaks, as this new interface is not compatible.Adapter Saves the Day
So, how do we handle this modified interface without changing our legacy code? You know the answer now, don't you? We write a simple adapter to modify its interface to adapt to the existing one as below:01020304050607080910111213141516171819publicclassAdvancedVideoControllerAdapterimplementsLegacyVideoController {privateAdvancedVideoController advancedVideoController;publicAdvancedVideoControllerAdapter(AdvancedVideoController advancedVideoController){this.advancedVideoController = advancedVideoController;}@OverridepublicvoidstartPlayback(longstartTimeTicks) {// Convert long into DateTimeTime startTime = getTime(startTimeTicks);// AdaptadvancedVideoController.seek(startTime);advancedVideoController.play();}}This adapter implements the target interface, which the client expects so there is no need to change the client code. We compose the adapter with an instance of the adaptee interface.This "has-a" relationship allows the adapter to delegate the client request to the actual instance.Adapters also help in decoupling the client's code and the implementation.We can now simply wrap the new object in this adapter and be done with it, without making any changes to the client code as the new object is now converted/adapted to the same interface.1234AdvancedVideoController advancedController = controllerFactory.createController();// adaptLegacyVideoController controllerAdapter =newAdvancedVideoControllerAdapter(advancedController);playBackVideo(20, controllerAdapter);An adapter can be a simple pass through or can be intelligent enough to provide some add-ons depending on the complexity of the interface to support. Similarly, one adapter can be used to wrap more than one object if the target interface is complex and the new functionality has been split across two or more classes.Comparison With Other Patterns
- Decorator : Decorator changes the interface and wraps an object around by adding new responsibility. On the other hand, adapter is used to convert the adaptee interface to target interface which is understood by the client.
- Facade : Facade works by defining a totally new interface abstracting the complexity of earlier interfaces while adapter is used to enable communication between incompatible interfaces by converting one into another.
- Proxy : Proxy provides the same interface. Whereas adapter provides a different interface to its subject.
- Bridge : Bridge is designed upfront to let the abstraction and the implementation vary independently but adapter is used to adapt to an existing interface by delegating the request to adaptee.
The Singleton Design Pattern
Though there are many patterns which deal with creation of objects, one specific pattern stands out. Today we're going to inspect one of the most simple, yet misunderstood, ones: the Singleton pattern.As the name suggests, the purpose of the singleton is to create a single instance of the class and provide global access to it. Examples can be an application levelCache, an object pool of threads, connections etc. For such entities, one and only instance must suffice else they threaten the stability and defeat the purpose of the application.Implementing the Singleton Pattern
A bare-bones implementation in Java would look like:01020304050607080910111213141516171819publicclassApplicationCache{privateMap<String, Object> attributeMap;// Static instanceprivatestaticApplicationCache instance;// Static accessor methodpublicstaticApplicationCache getInstance(){if(instance ==null){instance ==newApplicationCache();}returninstance;}// private ConstructorprivateApplicationCache(){attributeMap = createCache();// Initialize the cache}}In our example, the class holds a static member of the same type as that of the class, which is accessed via a static method. We make use of Lazy Initialization here, delaying the initialization of the cache, until it is actually needed at runtime. The constructor is also made private so that a new instance of this class cannot be created using thenewoperator. To fetch the cache, we invoke:12ApplicationCache cache = ApplicationCache.getInstance();// use cache to improve performanceIt works perfectly fine as long as we are dealing with a single-threaded model. But life, as we know it, is not that simple. In a multi-threaded environment, you need to synchronize the lazy initialization or just do away with it, by creating the cache as soon as the class is loaded, either by using static blocks or initializing while declaring the cache.Double Checked Locking
We synchronize the lazy initialization to make sure that the initialization code is run only once. This code works with Java version 5.0 and above due to idiosyncrasies associated with the implementation ofsynchronizedandvolatilein Java.010203040506070809101112131415161718192021222324publicclassApplicationCache{privateMap<String, Object> attributeMap;// volatile so that JVM out-of-order writes do not happenprivatestaticvolatileApplicationCache instance;publicstaticApplicationCache getInstance(){// Checked onceif(instance ==null){// Synchronized on Class level locksynchronized(ApplicationCache.class){// Checked againif(instance ==null){instance ==newApplicationCache();}}}returninstance;}privateApplicationCache(){attributeMap = createCache();// Initialize the cache}}We make the instance variable volatile so that the JVM prevents out-of-order writes for it. We also do a double null check (hence the name) for instance while synchronizing the initialization so that any sequence of 2 or more threads does not corrupt the state or result in creation of more than one instance of the cache. We could have synchronized the whole static accessor method instead, but that would have been an overkill as synchronization is only needed until the object is fully initialized; never again while accessing it.No Lazy Initialization
An easier way would be to do away with the benefits of lazy initialization, also resulting in cleaner code:010203040506070809101112131415publicclassApplicationCache{privateMap<String, Object> attributeMap;// Initialized while declarationprivatestaticApplicationCache instance =newApplicationCache();publicstaticApplicationCache getInstance(){returninstance;}// private ConstrucutorprivateApplicationCache(){attributeMap = createCache();// Initialize the cache}}As soon as the class loads and the variables are initialized, we invoke the private constructor to create the one and only instance of the cache. We lose the benefits of lazily initializing the instance but the code is much cleaner. Both methods are thread-safe and you can choose the one suitable for your project environment.Safeguard Against Reflection and Serialization
Depending on your requirement, you might also want to protect against:- Code using Reflection API to invoke the private constructor, which can be dealt with by throwing an exception from the constructor, in case it is called more than one time.
- Similarly serializing and de-serializing the instance might also result in two different instances of our cache, which can be handled by overriding the
readResolve()method from the Serialization API
Design Patterns are Language Agnostic
The title of our tutorial is a bit misleading, I admit, as design patterns are really language-agnostic. They are simply a collection of the best design strategies developed to counter recurring problems faced in software design. Nothing more, nothing less.For example, below is a quick look at how we could implement asingletonin Javascript. The intent remains the same: controlling the creation of the object and maintaining a global point of access, but the implementation differs with the constructs and semantics of each language.01020304050607080910111213141516171819202122232425262728varapplicationCache =function() {// Private stuffvarinstance;functioninitCache() {return{proxyUrl:"/bin/getCache.json",cachePurgeTime: 5000,permissions: {read:"everyone",write:"admin"}};}// Publicreturn{getInstance:function() {if(!instance) instance = initCache();returninstance;},purgeCache:function() {instance =null;}};};To quote another example, jQuery also makes heavy use of the Facade design pattern, abstracting away the complexity of a subsystem and exposing a simpler interface to the user.Closing Remarks
Not every problem requires the use of a specific design patternA word of caution is necessary: do not overuse! Not every problem requires the use of a specific design pattern. You need to carefully analyze the situation before settling on a pattern. Learning design patterns also helps in understanding other libraries like jQuery, Spring etc which make heavy use of many such patterns.I hope that, after reading this article, you're able to get a step closer in your understanding of design patterns. If you have any questions or want to learn additional design pattern, please let me know within the comments below, and I will do my best to answer your questions!
Subscribe to:
Posts (Atom)